3 ms·

>git rebase enables users to rewrite history which subverts what should be the main, if not only, function of a version control system. This is a common compla

by jasode 12y ago

>git rebase enables users to rewrite history which subverts what should be the main, if not only, function of a version control system. This is a common complaint but it's based on a preconceived notion of the word "history" rooted in intuition instead of re-evaluating what "history" means in the universe of Git. (Actually the generalized universe of DVCS and not just Git.) One type of "history" is something immutable and suitable for forensics. Examples such as a history log file of changed bytes written to database blocks. This history must be perfect and unchangeable or things like db recovery and master+slave replication will not work. Another example is "history" of financial credits and debits across accounts. That type of "history" shouldn't be changed because it would render financial audits and fraud investigations useless. In Git, there's another perspective on "history". It is a "history for public dissemination" which is very different purpose than database log history or financial accounts transaction history. Since the "D" in DVCS is "distributed", it's this "history for public consumption" that expands how "history" should be viewed in Git/DVCS. If you're working 100% local private repository and never collaborating with others, you can avoid rebase and just do merges. However, as a social courtesy to other distributed programmers, rebase is a cleaner public presentation of new changes for others to see/review. Whether you did your work against on a public tree you pulled down on Monday or Wednesday makes no difference to people upstream looking at your changes. Rebase eliminates a lot of noise. It's letting go of forensics type history and embracing social public consumption type of history. This type of disseminated history was important enough that Mercurial also added an extension for it[1] [1]http://mercurial.selenic.com/wiki/RebaseExtension http://mercurial.selenic.com/wiki/RebaseExtension

NumberSix 12y ago
When I am debugging a complex program, I need the "real history" to find subtle bugs as quickly as possible. Similarly, if the project is shared with others and they need to debug my code efficiently, they will need access to the actual history, warts and all, not a "history for public dissemination" produced by the project's Ministry of Truth. Version control systems were developed to enable developers to quickly and efficiently find the specific change that caused a bug or other problem discovered later. Rewriting history, for example squashing numerous changes into a single commit using Git's interactive rebase, defeats this main purpose of version control. It is difficult to see a good reason for a "history for public dissemination." This is the sort of thing Orwell decried in Animal Farm and 1984 as well as his factual writing. Instead of highly subjective code reviews that introduce politics and personal prejudice, focus on objective tests of the performance of the software. The more sensible approach is to share the project's actual development history for developers and tag production releases and release candidates in some way. Obviously only developers need to worry about non-production versions of the code. Bit by Git
- jasode 12y ago
  The Linux kernel has ~15 million lines-of-code with 1100+ contributors. I think you would agree they have to deal with complex and subtle bugs as well. They also extensively use rebase. Dealing with a thousand commits that say "fixed spelling error in code comment" to satisfy your idea of "pure unchanged history" would be maddening. In any case, it's a matter of perspective I guess. In Git workflow, the "real history" --> git reflog. the "idealized history" is output of --> git rebase. If I interpreted you correctly, what you want is: "real history" --> git log "idealized history" --> git tag -l It's understandable you feel that way but I'm glad Git chose the first way. It fits better with the philosophy of the "D" in DVCS.
- danieldk 12y ago
  Version control systems were developed to enable developers to quickly and efficiently find the specific change that caused a bug or other problem discovered later. Rewriting history, for example squashing numerous changes into a single commit using Git's interactive rebase, defeats this main purpose of version control. That's not a problem of git, but the person using it. In fact, I often saw people using Subversion making jumbo commits, since Subversion makes it so hard to split changes in a working tree up in multiple commits and makes branching painful. You mention finding bugs. I'd rather look at a history that was rewritten in 5 tidy commits than 10 commits where 5 are 'fixed indenting', 'fixed typo', or intermediate data structure changes.

by jasode 12y ago

NumberSix 12y ago

When I am debugging a complex program, I need the "real history" to find subtle bugs as quickly as possible. Similarly, if the project is shared with others and they need to debug my code efficiently, they will need access to the actual history, warts and all, not a "history for public dissemination" produced by the project's Ministry of Truth. Version control systems were developed to enable developers to quickly and efficiently find the specific change that caused a bug or other problem discovered later. Rewriting history, for example squashing numerous changes into a single commit using Git's interactive rebase, defeats this main purpose of version control. It is difficult to see a good reason for a "history for public dissemination." This is the sort of thing Orwell decried in Animal Farm and 1984 as well as his factual writing. Instead of highly subjective code reviews that introduce politics and personal prejudice, focus on objective tests of the performance of the software. The more sensible approach is to share the project's actual development history for developers and tag production releases and release candidates in some way. Obviously only developers need to worry about non-production versions of the code. Bit by Git

jasode 12y ago
The Linux kernel has ~15 million lines-of-code with 1100+ contributors. I think you would agree they have to deal with complex and subtle bugs as well. They also extensively use rebase. Dealing with a thousand commits that say "fixed spelling error in code comment" to satisfy your idea of "pure unchanged history" would be maddening. In any case, it's a matter of perspective I guess. In Git workflow, the "real history" --> git reflog. the "idealized history" is output of --> git rebase. If I interpreted you correctly, what you want is: "real history" --> git log "idealized history" --> git tag -l It's understandable you feel that way but I'm glad Git chose the first way. It fits better with the philosophy of the "D" in DVCS.
danieldk 12y ago
Version control systems were developed to enable developers to quickly and efficiently find the specific change that caused a bug or other problem discovered later. Rewriting history, for example squashing numerous changes into a single commit using Git's interactive rebase, defeats this main purpose of version control. That's not a problem of git, but the person using it. In fact, I often saw people using Subversion making jumbo commits, since Subversion makes it so hard to split changes in a working tree up in multiple commits and makes branching painful. You mention finding bugs. I'd rather look at a history that was rewritten in 5 tidy commits than 10 commits where 5 are 'fixed indenting', 'fixed typo', or intermediate data structure changes.