I'm not a git user (it's true, I'm not a professional dev and use fossil for my pet projects) so honest question: why would you want to rewrite your history?
One use case: you adopted a (new?) formatter, now tracking the evolution of a line/its vicinity is a lot more difficult past that. So you apply the formatter to every commit since the beginning. Literally it's not the true history of what the code looked like, but semantically it is, and it's more useful.
Splitting subfolder into separate repo is full history rewrite.
Changing commit message or commit tree is full history rewrite.
Also, if you maintain local changes, you want your rebase onto vendor be super easy, meaning you want to groom your history into nice set of changes, not "reverted: reverted: really fix bug #123 for real" tangle.
Rebase itself is a history rewrite.
Personality have needed for the following reasons (when wanting to preserve history): removing personal info, removing sensitive keys/passwords that were accidently committed a long time ago, splitting a repo. There's lots of use cases
I support anti-dox/and security practices by cleaning up repo history and rotating where you can, as long as your safe with the assumption that anyone with a copy of the history could push it back to central at any point.
But I really don't like the trend of some folks "need a clean history" and then disabled merge commits.
It's like they are saying "cool snap shot system you got there, id hate for it to be use to take a bunch of incremental snap shots with specific notes attached to each one. Why don't you let me bundle those all together real purdy like and no one has to know it took you 20 commits to fix that decade old bug."
I have literally never heard a reasonable claim that needing a "clean main branch" is more useful in a retro or bisect.
>"cool snap shot system you got there, id hate for it to be use to take a bunch of incremental snap shots with specific notes attached to each one. Why don't you let me bundle those all together real purdy like and no one has to know it took you 20 commits to fix that decade old bug."
It’s more like saying “in any writing process, revising is going to lead to better finished output.” It is absolutely true that no one needs to know that it took you 20 commits to fix that bug. It’s much easier to review 3 commits, one of which contains the refactoring done as part of the fix with the other two each containing changes that address distinct pieces of the bug. The structure of the change is clearer, and the structure of the attached notes will be clearer as well.
I don't think all writing process produces the same kinda of output, the editing of code itself is metadata I find more valuable and an artificially straight line.
- Because the history actually represents causality and not wall clock time, and a change belongs logically and semantically into some other changeset.
- Because you want to restructure the project for the whole history, prior to merging several projects.
Finding this usefull on migration. But I am puzzled when the migration has changed the file names and put the files on a new path, especially copying the files into a separate folder (non git) and the creating the version controlled folder which serves as the final codebase
By Elijah Newren, author of Git's newer mergeort merge algorithm. ("ort" or "ostensibly recursive's twin" replaced the older recursive merge algorithm.)
I'm not a git user (it's true, I'm not a professional dev and use fossil for my pet projects) so honest question: why would you want to rewrite your history?
One use case: you adopted a (new?) formatter, now tracking the evolution of a line/its vicinity is a lot more difficult past that. So you apply the formatter to every commit since the beginning. Literally it's not the true history of what the code looked like, but semantically it is, and it's more useful.
Splitting subfolder into separate repo is full history rewrite. Changing commit message or commit tree is full history rewrite. Also, if you maintain local changes, you want your rebase onto vendor be super easy, meaning you want to groom your history into nice set of changes, not "reverted: reverted: really fix bug #123 for real" tangle. Rebase itself is a history rewrite.
Personality have needed for the following reasons (when wanting to preserve history): removing personal info, removing sensitive keys/passwords that were accidently committed a long time ago, splitting a repo. There's lots of use cases
I support anti-dox/and security practices by cleaning up repo history and rotating where you can, as long as your safe with the assumption that anyone with a copy of the history could push it back to central at any point.
But I really don't like the trend of some folks "need a clean history" and then disabled merge commits.
It's like they are saying "cool snap shot system you got there, id hate for it to be use to take a bunch of incremental snap shots with specific notes attached to each one. Why don't you let me bundle those all together real purdy like and no one has to know it took you 20 commits to fix that decade old bug."
I have literally never heard a reasonable claim that needing a "clean main branch" is more useful in a retro or bisect.
Maybe other folks know of a concrete example?
>"cool snap shot system you got there, id hate for it to be use to take a bunch of incremental snap shots with specific notes attached to each one. Why don't you let me bundle those all together real purdy like and no one has to know it took you 20 commits to fix that decade old bug."
It’s more like saying “in any writing process, revising is going to lead to better finished output.” It is absolutely true that no one needs to know that it took you 20 commits to fix that bug. It’s much easier to review 3 commits, one of which contains the refactoring done as part of the fix with the other two each containing changes that address distinct pieces of the bug. The structure of the change is clearer, and the structure of the attached notes will be clearer as well.
I don't think all writing process produces the same kinda of output, the editing of code itself is metadata I find more valuable and an artificially straight line.
It looks pretty :)
- Because the history actually represents causality and not wall clock time, and a change belongs logically and semantically into some other changeset.
- Because you want to restructure the project for the whole history, prior to merging several projects.
This tool really helped when I was migrating code across repositories. Thanks a lot!
Finding this usefull on migration. But I am puzzled when the migration has changed the file names and put the files on a new path, especially copying the files into a separate folder (non git) and the creating the version controlled folder which serves as the final codebase
The same here! Merged several repos into monorepo are retained full history!