Re: Git workflow (was: Re: Planner xml field additions)

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:
> 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
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.


Maurice van der Pot

Gentoo Linux Developer   griffon26 gentoo org
Gnome Planner Developer  griffon26 kfk4ever com

Attachment: pgpT0h04fcpBl.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]