| |||||||||||||
Bazaar on the slow trackBazaar on the slow trackPosted Sep 19, 2012 14:22 UTC (Wed) by pboddie (subscriber, #50784)In reply to: Bazaar on the slow track by dlang Parent article: Bazaar on the slow track
note that git doesn't force you to throw away the history. I think that the intention may have been to describe the apparently common practice, particularly amongst git-using projects, of aggressively rebasing everything and asking people to collapse their contributions into a single patch so that the project history is kept "clean".
(Log in to post comments)
Bazaar on the slow track Posted Sep 19, 2012 15:31 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
one of the features of git is the ability to recreate and combine patches before pushing them upstream.
Yes, this can be abused to combine a huge amount of work into one monster patch.
But it can be used sanely to re-order and combine patches from a line of development into a clean series of logical patches.
When you are developing something, if you check it in frequently as you go along, you are going to have cases where you introduce a bug at one point and don't find and fix it for several commits. You are also going to have things that you do at some point that you find were not the best way to do something and that you change back later (but want to keep other work you have done in the meantime)
you now have the option of either pushing this history, including all your false starts, bugs, etc.
Or you can clean the history up, combining the bugfixes with the earlier patches that introduced the bug, eliminating the false starts, etc and push the result.
The first approach has the advantage that everything is visible, but it has the disadvantage that there are a lot of commits in the history where things just don't work.
If the project in question encourages the use of bisect to track down problems, having lots of commits where things just don't work makes it really hard for users trying to help the developers track down the bugs.
As a result, many projects encourage the developers to take the second approach.
Now, many developers misunderstand this to mean that they are encouraged to rebase their entire development effort into one monster patch relative to the latest head, but that's actually a bad thing to do.
And in any case, the history is still available to the developer, they are just choosing not to share that history with the outside world.
Bazaar on the slow track Posted Sep 19, 2012 19:52 UTC (Wed) by smurf (subscriber, #17840) [Link]
What he said.
A "clean" history (meaning "to the best of my knowledge, every change transforms program X1 into a strictly better program X2") means that you can take advantage of one of git's main features when you do find a regression.
Bisecting.
If you do break something, "git bisect" requires ten compile-test-run cycles to find the culprit, among a thousand changes. Or twenty cycles if you have a million changes. (OK, more like 13 and 30, because history isn't linear, but you get the idea.) If you try to keep track of that manually you'd go bonkers.
Of course this isn't restricted to git. bzr and hg also implemented the command. The idea was too good not to. ;-)
|
|||||||||||||