On Sun, Jan 4, 2009 at 12:52 AM, Victor <[email protected]> wrote:
> trouble understanding what git rebase does. I've read the > documentation for git-rebase at > http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html > but it still doesn't make sense to me (I usually only ever use git > add, rm, stash, reset, pull, push, fetch, commit and gui). As far as I > can tell, git-rebase stashes away your current commits that are ahead > of origin, puts origin as the head, then applies your commits again, > leaving you on square one, with the exception that any commits that > have already been accepted upstream are not applied, since it would > just do the same thing. Even so, that's not much of an exception, > right? > > What am I missing about git-rebase/what do you use it for in layman's > terms? Firstly, it is important to note that you should never (or almost never) rebase a branch which has already been pushed to anyone else -- it causes all sorts of problems for them, because you've changed "history" behind their backs. With that out of the way... What rebase does is that it "linearises" the history of the final merged master branch. Let's say your changes look like this: A-->B-->C-->D-->E \-->P-->Q-->R You opened a topic branch when master was at A. Now the topic is at R, master at E. A merge then combines E and R into a new node, which may be "F". But the history tree now has a non-linearity in it. If you rebase, the history looks like A-->B-->C-->D-->E-->P2-->Q2-->R2 where P2, Q2, and R2 are the same textual change as in the original P/Q/R, but they are made on top of E instead of on top of A. One practical reason to use rebase is described very nicely at http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-merges In general, it is easier to debug stuff if history is linear :-) Another one is that without a rebase, a master that receives a tree to pull cannot easily cherry-pick changes. Well he can, but the chances of conflicts are a little higher cherrying picking a change from an older version of your tree than one built on your latest tip. In the example above, if master were offered the PQR tree for a pull, let's say he decided to take only change Q because the other 2 were not acceptable. Picking up Q , which is built on A, when master is currently at E, puts the onus of any conflict resolution on the person handling "master". (I guess he could say "hey topic guy, I like Q, so give me a branch which only contains Q and I will pull from there", but I suppose that wastes time...) However, if the topic guy take the trouble to rebase, and then offer the master a P2/Q2/R2 branch for a pull, the chances of the "master" maintainer finding a conflict are much lesser, because Q2 is built on top of E, which is either the current master tip or very close to it. This **really** makes a difference if your A was old (which can happen if your topic was a complex feature that took you a while to develop and get stable enough to offer for a merge with master, so that meanwhile master has moved quite a bit). A third reason is that many people like the master project history to be linear rather than full of merges. For small teams or frequent pushes to master this may not be a problem, but for large projects like Linux, where a single change can go up many levels of review and approval before it gets to Linus' tree, it makes a lot of difference -- the project history would be horribly convoluted! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
