On Sat, Apr 25, 2009 at 06:11:43AM -0400, Kurt Maute wrote: > I'm really not clear on the whole rebase concept yet, but this article > helps a bit: > http://www.gitready.com/intermediate/2009/01/31/intro-to-rebase.html > > Not sure what you mean by rebasing branches that people have branched > from? Is it something like this: ? > > o--o <-- Branch Aa > / > o--o--o <--Branch A > / > o--o--o--o <-- Master > > ... and don't rebase Master from Aa? I meant that you should not rebase A to the head of master if someone else has branched your branch (as is the case with Aa). > o--o <-- Branch Aa > / > o--o > / > | o--o--o <-- Branch A > | / > o--o--o--o <-- Master This rebase would make it look like your branch split off of master at the current HEAD instead of whichever commit was HEAD when you branched. This is not a problem if you are the only one using your branch, but if someone else branched from it his git will get confused. I believe the reason is that commits on A may get a new ID after being rebased on the head of master. Some of those commits (the ones that are part of the history of Aa) will also remain in the repository under their old ID. Git won't see that they are the same and will consequently produce conflicts when merging Aa with master for instance. Also an interactive rebase lets you edit the order of commits, delete commits, squash multiple commits into one, etc. This is the cleaning up functionality that may be useful for a topic branch that went through a lot of experimentation and rewriting. Now if you are working on a topic branch on your own, then rebase is actually a good thing to use. You do not want your history littered with "merge" commits if all you wanted to do was check if your code in progress still worked with the latest master. In the case multiple people are working on a topic branch, they can discuss for themselves if/when they want to rebase. Some options they would have are: 1) don't rebase, just merge in master at certain points in time. Merging doesn't cause unnecessary conflicts for people who have branched from this topic branch. 2) agree to do a rebase and have everybody create a clean branch afterwards. 3) a combination of both. You could merge during development and rebase once you think it's done. Linus has a point when he says that this invalidates the testing you have done on the code before the rebase. So if we just rebase our private branches and stop rebasing if they become public for collaboration, and if we also do not merge from master continuously, then we can always decide at a later stage if we still need to clean up or if we can merge to master straightaway. > I don't really understand how someone would destroy someone else's > history I think they mean if you have been pulling other people's work into your branch (for instance some kernel developer pulling from some contributor) and you rebase (and clean up) before you push it upstream (or Linus pulls from you), the upstream branch will not get the history as it was in the downstream branches you pulled from. Regards, Maurice. -- Maurice van der Pot Gentoo Linux Developer griffon26 gentoo org http://www.gentoo.org Gnome Planner Developer griffon26 kfk4ever com http://live.gnome.org/Planner
Attachment:
pgpT0h04fcpBl.pgp
Description: PGP signature