From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:22
Matt McCutchen [off-list ref] writes:
I made a customized Linux kernel based on 2.6.15.6 by cloning the stable
2.6.15 kernel repository (which was then at version 2.6.15.6) and making
several commits. Now I would like a Linux kernel based on 2.6.16 with
the same customizations.
Drawing ancestry graph would help visualizing what you want to
achieve. You have:
v2.6.15
---o
\
\
\
o---o---o v2.6.15.6
\
x---x---x v2.6.15.6-matt
where x---x---x are your own changes, and you want:
v2.6.15 v2.6.16
---o---o---o---...---o---o
\ \
\ y---y---y 2.6.16-matt
\
o---o---o v2.6.15.6
\
x---x---x 2.6.15.6-matt
to happen, where y---y---y are analogous to x---x---x.
Assuming your branches are:
origin - v2.6.15.6 (from stable team)
master - your changes (2.6.15.6-matt)
you could:
$ git fetch git://../torvalds/linux-2.6.git tag v2.6.16
$ git checkout -b 2.6.16-matt v2.6.16
$ git format-patch origin master | git am -3
Alternatively, you might want to do a real merge:
v2.6.15 v2.6.16
---o---o---o---...---o---o
\ \
\ \
\ m 2.6.16-matt
o---o---o v2.6.15.6 /
\ /
x---x---x 2.6.15.6-matt
Presumably the stable team backported safer changes from the
history between v2.6.15-v2.6.16, and the way things are fixed
are probably quite different from the equivalent fixes in the
development track that led to v2.6.16 (because what's being
patched has also changed), so it is very likely you would see
serious conflicts during this merge. If you do not understand
what the stable team did in order to reimplement certain fixes,
you would have a very difficult time deciding on how to resolve
conflicts with this merge.
At that point it would not be a git question but the kernel
question I am not qualified to answer ;-), but it might be an
interesting exercise.
From: Matt McCutchen <hidden> Date: 2016-06-15 22:42:22
On Tue, 2006-03-28 at 18:26 -0800, Junio C Hamano wrote:
v2.6.15 v2.6.16
---o---o---o---...---o---o
\ \
\ y---y---y 2.6.16-matt
\
o---o---o v2.6.15.6
\
x---x---x 2.6.15.6-matt
to happen, where y---y---y are analogous to x---x---x.
Assuming your branches are:
origin - v2.6.15.6 (from stable team)
master - your changes (2.6.15.6-matt)
Beautiful diagram. This is exactly my situation.
you could:
$ git fetch git://../torvalds/linux-2.6.git tag v2.6.16
$ git checkout -b 2.6.16-matt v2.6.16
$ git format-patch origin master | git am -3
This looks like what I want. When I run the third command, however, I
get "no patch found". Four files corresponding to my four commits
appear in my repository; I have attached them. What is wrong?
Alternatively, you might want to do a real merge:
[...] If you do not understand
what the stable team did in order to reimplement certain fixes,
you would have a very difficult time deciding on how to resolve
conflicts with this merge.
Yes, I think this is the problem what I ran into before when I was
trying to pull.
Perhaps this is just politics, but which kernel repository is more
official, and why? Linus's or the one I have been using,
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
?
Thanks for the help!
--
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/
Perhaps this is just politics, but which kernel repository is more
official, and why? Linus's or the one I have been using,
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
?
The beauty of git should be (and maybe that's not entirely true simply
because of practical concerns) that there really need not be any notion of
"more official".
You can fetch multiple different git trees from different sources into the
same git tree, and then keep them _all_ around equally as different
branches. You can move fixes between the different branches with "git
cherry-pick", and you can merge different branches with "git merge"
Now, the reason I say "_should_ be" rather than "is" is two-fold:
- right now, a lot of the infrastructure is simply set up more towards
the "one single source repository" model. When you do a "git clone", it
kind of makes the origin special. That's how all the documentation is
written, and that's also the only remote branch that git creates
_automatically_ for you.
This really isn't a technical issue: the git code code doesn't care
about any special "original" repository. But the fact that you have to
create the ".git/remotes/linus" file by hand, and that all the examples
in the docs end up talking about a single "origin" branch means that
people _think_ of git as a "single origin" thing.
- the more fundamental one is that when you start mixing branches, you
have to be very careful if you expect the upstream projects to pull the
changes _back_. In particular, that's where you have to think twice (or
three times) about doing a "git merge" (or a "git pull", which
implicitly merges for you if it's not a pure fast-forward).
In particular, the fact that _you_ want to merge two trees that came
from different sources does _not_ imply that either of the two sources
might want to merge with each other. So if you merge the two together,
you may find it impossible to have either of them then pull from you:
they way want your changes, but they might not like the merge you did,
because they have different policies about that work than you did.
So while the first point is purely a "mental model" issue and about lack
of helper scripts, the second point is fundamental.
For example, in your case it was almost certainly the right thing to do to
cherry-pick your changes from the 2.6.15.6 branch onto the development
branch, because I simply don't want to merge the 2.6.15.6 stuff into the
standard tree: part of the _rules_ for the stable branch is that the
things it fixes should have been fixed in the development tree already, so
merging the stable tree should always be unnecessary (and often clash,
although _hopefully_ in many cases the fixes in the stable tree are 1:1
identical and will merge beautifully).
Anyway: from a technical standpoint, no tree should be "special" or "more
official" for git usage. But when merging data back to any of those trees
that aren't special, the source/history of the data is important to keep
in mind. Branch "a" may not be any more special than branch "b", but when
you push changes back to the source of branch "a", the history of those
changes (relative to what the source was) is meaningful.
Linus
From: Matt McCutchen <hidden> Date: 2016-06-15 22:42:22
On Thu, 2006-03-30 at 09:32 -0800, Linus Torvalds wrote:
The beauty of git should be (and maybe that's not entirely true simply
because of practical concerns) that there really need not be any notion of
"more official".
I understand this, and it is one of several reasons why I prefer git to
other version control systems. However, I thought there would be a
single official kernel repository even if git didn't require it. Junio
explained to me that both yours and the stable one are official for
different purposes. I think I will use the stable one because it is
current enough for my needs.
- the more fundamental one is that when you start mixing branches, you
have to be very careful if you expect the upstream projects to pull the
changes _back_. [...]
True. It might help several branches coordinate development if a commit
could be marked as "equivalent" to another commit so that, if both were
involved in a merge, one could be thrown out.
--
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/