Re: What's in git.git

Junio C Hamano wrote:

Andreas Ericsson [off-list ref] writes:

quoted

sean wrote:

quoted

I've always followed it okay by just using "git branch -d pu" each
time before pulling from you.   Your "next" branch does sound like
an improvement though.

I thought

Pull: +pu:pu

was supposed to handle such things automatically. It has always pulled
properly for me anyways.

Yes, fetching to look at is no problem, but what I wanted to
solve is that you cannot easily _touch_ it.  The point of this
is to make improving on top of what is still _not_ in master
easier for the contributors.

If you want to improve upon what is in the current "pu", the
natural thing for you to do would be:

	$ git fetch git://git.kernel.org/pub/scm/git/git +pu:pu
	$ git checkout -b my-pu pu ;# initial
        $ hack on it and git commit many times
        $ git format-patch --stdout pu..my-pu |
          git send-email --to junkio@cox.net --cc git@vger.kernel.org

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

(Side note: I do not know git-send-email would work like the
above, but if it did that might be handy.  Ryan?)

With my (still un-published) git-send-patch you could do

	$ work, work, work
	$ git send-patch -s "Some subject for a prelude message" pu

and it would do the right thing.

I guess I'll have to get around to sending that thing in sooner or later.

But sometimes you may take more time than how my "pu"
progresses, and you would want to sync your work to my updated
"pu".  A natural thing you would want to do is this:

        $ git pull git://git.kernel.org/pub/scm/git/git +pu:pu

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

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

Unfortunately, this would _not_ work very well, because by the
time you pull from my "pu" again, it would have rewound and
rebased.  You would end up seeing unnecessary merge conflicts.

Another possibility would be:

        $ git fetch git://git.kernel.org/pub/scm/git/git +pu:pu
        $ git rebase pu

Using my own topic-branch, this is what I always do. Conflicts that 
occur that way are always in my patches, so they would have to be 
reworked anyway. The new rerere tool should help if I dally too long.

Perhaps I'm just weird, but I never touch published branches.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231