Re: What's in git.git

[Junio C Hamano <junkio@cox.net>]

Andreas Ericsson <ae@op5.se> writes:

> This is exactly what I do when I improve upon things in master, and
> according to numerous emails this is the recommended workflow.

Yes.

> Do you mean
> 	$ git pull git://git.kernel.org/pub/scm/git/git +pu:my-pu

I do mean "+pu:pu".  In my illustration, "pu" is used in your
repository to track "pu" retrieved from me, and "my-pu" is a
fork you created from it and you build your changes upon.

	$ git pull $URL +pu:my-pu

is a shorthand for:

	$ git fetch $URL +pu:my-pu
        $ git merge "auto merge message" HEAD my-pu

and you definitely do not want to _fetch_ into my-pu when you
are on my-pu.

> ? Otherwise, I don't see how I can end up with merge-conflicts.

The problem is exactly why you need the plus sign when you fetch,
i.e. "+pu:pu".  My "pu" rebases.

Suppose I had this:

             o--o--o
            /      "pu"
	o--o
           "master"     

You do fetch +pu:pu, branch my-pu, and build on top of it:

                     o--o--o--o--o--o--o
                    /                  "my-pu"
             o--o--o
            /      "pu"
	o--o
           "master"

I add some to my "master" and rebuild "pu", maybe while adding
another commit on "pu".  You fetch +pu:pu again:

                     o--o--o--o--o--o--o
                    /                  "my-pu"
             o--o--o        o--o--o--o
            /              /         "pu" 
	o--o--o--o--o--o--o
                          "master"

Now, what happens when you merge "pu" into "my-pu"?  The three
commits I had on my previous "pu" are not part of the history of
the updated "pu" anymore, but is considered to be part of your
development trail.  If these had an addition of a file, and if
your development on top of the previous "pu" modified it, the
merge would result in:

 * originally the file did not exist.
 * "pu" adds it one way.
 * "my-pu" adds it in another way.

This requires a hand merge.  What should be done is for me to
instead of rebasing "pu", merge the updated master to "pu".

                     o--o--o--o--o--o--o
                    /                  "my-pu"
             o--o--o--------*--o
            /              /   "pu" 
	o--o--o--o--o--o--o
                          "master"

Then merge between "my-pu" and "pu" become easier.  You do not
have to worry about the earlier three commits, because the point
you forked from the previous "pu" becomes the merge base.

The reason I have not done it that way so far is primarily I am
lazy and also I do not like to see too many merges in the log.
Also "pu" tends to have really wacky stuff, so separating out
only usable bits, excluding wacky ones is slightly easier if I
rebuild it from scratch.

The new "next" aka "not too close to bleeding or broken edge"
branch will be managed like the last picture above, in order to
make working with it easier to manage.  This is only usable if I
do not include too bleeding-edge topic branch in it.