Re: Best way to generate a git tree containing only a subset of commits from another tree?
- From
Andreas Ericsson <ae@op5.se>
- Date
- Mar 23, 2006, 03:20 UTC
- Message-ID
- <442213F4.7040603@op5.se>
- In-Reply-To
- <7vu09q54a6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes: >
>>If you have several topic branches, one for each series of commits,
Show 10 quoted lines
>>you should be able to do an octopus, like so: >> >> $ git pull . <topic-branches-to-publish> > > > Octopus is orthogonal to the issue at hand. Further, I suspect > that the original repository by Anton is not that cleanly > organized to have such topic branches -- otherwise the question > would not have come up to begin with. >
<sidenote> I've never understood what orthogonal means in this sense. "at a right angle" as in flagging for attention or the exactly counter-productive to what one should use? </sidenot>
Show 20 quoted lines
> >>If you *don't* have several topic branches, or if some commits aren't >>in topic-branches, you could try something like this (untested, >>although it shouldn't break anything except the for-linus branch which >>you can re-create fairly simply) >> >> $ for b in <topic-branches-for-linus>; do >> git checkout $b >> git rebase for-linus || (git reset --hard; echo $b >> to-merge) >> done > > >> # now merge what couldn't be rebased >> $ git checkout for-linus >> $ git pull . $(cat to-merge) > > > Now you lost me here. When rebase refuses because of > conflicting changes, you are doing "reset --hard" but I suspect > you meant "reset --hard ORIG_HEAD" to recover the original head.
I actually meant to reset the for-linus branch, although it would have to be reset to the state it was before trying the rebase, which means creating and deleting a tag or some other marker.
I really should install an alco-lock on my MUA.
> Further, I would have expected you to be rebasing on top of > linus, not for-linus, in case you may already have pulled other > topic branches into it. >
Perhaps. I said 'for-linus' to make sure there was an easy way to recover to state 1 in case of errors. I also rewrote the part above twice to account for topic branches, so it doesn't make much sense without the background thinking.
Show 6 quoted lines
> Your merging those branches that have conflicting changes on top > of for-linus (that starts out at Linus's tip) is sensible, but > one word of caution is the history contained within the topic > branch should be sane. What are you going to do with branches > that cleanly rebase on top of for-linus? >
Nothing. 'for-linus' should be updated each time a rebase completes success-fully, so all the cleanly rebased branches should be in a linear commit-history on top of each other. Granted, most projects won't have many topic-branches (or other commit-chains) that rebase on top of each other like that, but...
Show 16 quoted lines
> >>... If your vanilla tree is up-to-date and he pulls >>from you before pulling from someone else or adding other commits this >>isn't necessary, although you'll have to do >> >> $ git checkout linus; git pull . for-linus >> >>to get the vanilla branch up to speed with Linus' HEAD. > > > I am not sure I follow you here. > > If Linus hasn't pulled from you, you can either just keep asking > (you do not have to update for-linus), or rebuild it based on > more recent Linus's tip. >
What I meant was that the thing he has in "for-linus" will match what Linus has in "master" verbatim if Linus doesn't have commits on top of his "master" that aren't in Anton's "for-linus" (originating from "linus"). That sentence didn't make sense to me right now.
Show 6 quoted lines
> $ git fetch linus ;# to update to Linus's tip > $ git checkout for-linus > $ git reset --hard linus > > If Linus has pulled from you, there is nothing more than the > above for you to do.
The above command would reset the "for-linus" branch to the state it had before he applied all his changes. I meant that if he wants to track Linus' exact HEAD in some branch he could do that by tracking his own if the changes since merge-base are identical. I was clearly complicating things by mentioning such a highly conditional exception.
Show 12 quoted lines
> If you want to rebuild for-linus branch, > (maybe because you fixed things in some of your topic branches), > after the above, you could: > > $ git pull . this-topic > $ git pull . that-topic > ... > > This is nicer to Linus _if_ your topics overlap with recent > changes to the Linus's tree. Otherwise you do not necessarily > have to rebuild for-linus branch. >
But it's very nasty in case Linus has already pulled the changes, which was what I assumed he would have done.
I was most likely a bit diffuse. Everything else seems to be at the moment, and I like to blend in. ;)
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231