Re: What's in git.git
- From
Andreas Ericsson <ae@op5.se>
- Date
- Feb 9, 2006, 10:29 UTC
- Message-ID
- <43EB1984.3040602@op5.se>
- In-Reply-To
- <7vk6c4etzy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 31 quoted lines
> 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.
Show 6 quoted lines
> 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.
Show 9 quoted lines
> 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