Based on the help from this discussion and the rebase documenation,
what I ended up doing that seemed to require the fewest conflicts is
to use git merge-base to find the merge-base of master and 1.1 (the
oldest branch I wanted the feature) then I found the commit
immediately before the first commit on the feature branch (feature~3
in this case or commit a^). Then I rebased feature:
git rebase --onto merge-base-of-1.1-and-master feature-before-first feature
Turning this (hopefully not mangled by gmail):
future o-o-o-o-o-o-o
\ \ \
1.2 \ o-o-o \
\ \
1.1 o-o-o \
\
feature o-o-o
a b c
into this:
future o-o-o-o-o-o-o
|\ \
1.2 | \ o-o-o
| \
1.1 | o-o-o
\
feature o-o-o
a b c
I can merge 'feature' into 1.1, 1.2, etc. then theoretically, I should
be able to apply bug fixes to 'feature' later and re-merge into 1.1,
1.2, etc. to pick up just the bug fixes, right?
When I merged 'feature' into 'v1.1', it resulted in the same conflicts
I originally ran into when cherry-picking, but when I looked at it, I
realized this was because I had manually integrated some changes into
1.1 from master (I'm trying to move our tree from CVS to git so I had
to manually move in some stuff from CVS instead of doing a proper git
merge).
It seems like this merge conflict is going to cause problems if I try
to re-merge to pick up a bug fix to 'feature' in the future. Looking
at the documentation, it sounds like 'git rerere' can help by
re-applying the manual conflict resolution I did?
BTW...Is there a way to find the first commit of a branch? I had to
just look at the log manually to see what I remembered to be the first
commit.
--
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