Re: What's in git.git

[Andreas Ericsson <ae@op5.se>]

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> 
>>sean wrote:
>>
>>>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