On Wed, Nov 25, 2009 at 11:47 AM, Mike Jarmy <mjarmy@xxxxxxxxx> wrote:
> I guess I didn't explain it too well, I made it sound like v3, v4 and
> v5 were still more-or-less the same. What I'm thinking about here is
> a case where we have switched to git a while back, and then done a lot
> of work on the various different branches, so that v3, v4 and v5 have
> diverged very far from each other. In that case, we would never want
> to merge them together.
What many people do is, in fact, to merge v3->v4->v5.
This isn't as crazy as it sounds. Once upon a time, v4 was just an
earlier version of v3, right? And when you fix a bug in v3, it was
usually also a bug in v4, right? So in fact, for many projects, it's
safe to say that "after we created v4, all further changes to v3
should be propagated to v4." And likewise from v4 to v5.
In that case, you'd simply do
git checkout v3
# commit your fix
git checkout v4
git merge v3
Now, setting that up in the *first* place can be a bit tricky, since
the way your imported history probably currently works, git doesn't
actually know that the history of v4 is a superset of the history of
v3; it thinks of them as two totally different histories, and merging
from one to the other will be completely disastrous. So you have to
do a bit of setup first
# manually make sure all your required patches from v3 are now in v4.
# just do it the way you used to do it (the hard way)
# now tell git that it's done:
git checkout v4
git merge -s ours v3
After that, future merges from v3 to v4 will be easy (the first set of
steps above) and include only the newer changes.
Note that merging fixes back from v4 to v3 is entirely different,
because you'll *never* want to take *all* the changes from v4 and put
them into v3. The best thing to do is apply them to v3 first, then
merge them into v4, but of course that won't always be how developers
end up doing it. In that case, you can backport them using 'git
cherry-pick' (see the git docs).
Note that using topic branches, as Thomas and Jakub mentioned, is
orthogonal to this method. That is, your problem could be resolved by
doing that, or this, or both. (Although if the histories really are
totally disjoint, you'll still need to do something like the '-s ours'
trick first.) On my own projects, I do a bit of both methods; simple
bugfixes go straight to the earliest relevant release branch, but
bigger changes go on topic branches.
Have fun,
Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html