4 ms·

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 an

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.

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.