Andreas Ericsson [off-list ref] writes:
You would then do
$ git checkout -b for-linus linus
followed by either multiple
$ git cherry-pick <commit-ish>
or, if the commits are all in series, an iteration of the following
$ git format-patch --stdout <start-commit>..<end-commit> | git am -k
With core git tools these two would be the idiom to use. It
might be more pleasant to use a specialized tool (such as StGIT)
designed to manage the changes meant for upstream.
If you have several topic branches, one for each series of commits,
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.
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.
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.
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?
... 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.
$ 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. 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.
Junio C Hamano wrote:
Andreas Ericsson [off-list ref] writes:
>>If you have several topic branches, one for each series of commits,
quoted
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>
quoted
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
quoted
# 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.
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...
quoted
... 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.
$ 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.
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
On Thu, 23 Mar 2006, Andreas Ericsson wrote:
<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>
No. Orthogonal in math may be literally "straight angle", but in
non-geometric speak it means "independent" or "statistically unrelated".
See
http://wordnet.princeton.edu/perl/webwn?s=orthogonal
and the two first definitions in particular.
Ie two issues (or, in this case, "branches") are orthogonal if they have
nothing in common - they fix two totally independent things.
This is, btw, totally consistent with the geometric meaning of the word.
Two vectors are orthogonal if they have no common component: the dot
product is zero (ie the projection of one vector onto another is the null
vector).
So if you see two lines of development as being "vectors" from a common
source, when they have nothing in common, they are orthogonal.
Of course, the development space is neither three-dimensional nor
euclidian, so it's a strange kind of vector, but still ;)
Linus