| |||||||||||||
pull --rebasepull --rebasePosted Mar 20, 2012 17:12 UTC (Tue) by njs (guest, #40338)In reply to: pull --rebase by dlang Parent article: Git project seeks discussion on "push" change
> After you test the merge, you delete the branch, you defiantly don't do any more development on it.
> only when you are ready to push do you do a merge that will be visible to the outside world and push out.
I've seen people saying this for a while and it completely baffles me. Maybe you can explain.
What's so bad about merging from time-to-time as you work on your branch? That way you're sticking closer to upstream, can handle any changes and testing incrementally, and don't have to repeat merges over and over. I know it can work -- we did this all the time in monotone (the predecessor to git and hg), and it was wonderful. You end up with extra merges recorded in history, but who cares... they happened... they let future merges work better... instead we have kluges like git-rerere that try to tack a fake merge tool onto a system that already has a real one.
Back in the CVS days the inability to track merges into branches was considered one of the biggest bugs. Now that we fixed it, everyone seems to think that was actually a feature. Why?
(Log in to post comments)
pull --rebase Posted Mar 20, 2012 18:39 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
I'm not really a good person to explain the reasons behind this. I'm just passing on what I have learned from watching the discussions on the various discussion lists (especially the kernel and git lists)
I agree it sounds like it should improve development, but as I understand it, the actual result is that it complicates matters because you are pulling in unrelated changes with each merge. These unrelated changes may cause other problems along the way.
I suspect that how big an issue this is depends on the scope of the changes you are making.
If you are working on global-scale changes that touch lots of places, keeping up with upstream changes is more important, and just about all changes are relevant to the work that you are doing.
If you are working on a subsystem that is (relatively speaking) a small portion of the whole, then there are fewer benefits and more drawbacks.
pull --rebase Posted Mar 21, 2012 16:03 UTC (Wed) by misiu_mp (guest, #41936) [Link]
Here is how I see it: everybody likes a nice linear history. Fat trees with lots of merges are difficult to follow and thus not so useful, which is a good reason to merge less, at least in the public history.
The test-merge way of working is one way to do it: you make modifications, test-merge, make modifications, test-merge, make more modifications and perhaps make a final merge or even rebase. That would be fine if nothing relevant happened during those merges, so that you could have just as well not made them. I agree with you though, that relevant merges, where you needed to fix or change something, could (should?) stay in the history. As usual moderation should be the way to go. The great thing about git is that you have a choice.
|
|||||||||||||