Here's the scenario,
I have a muddled development branch that has a mix of local development and
upstream merges:
upstream 1--2--3--4--5
\ \ \
dev o--A--x--B--x ... Y
It took a lot of work, but I backported everything newer than A using rebase
and cherry-pick, and omitting the merges, giving me a dev' clean of merges
from upstream:
dev' o--A'--B' ... Y'
/
upstream 1--2--3--4--5
\ \ \
dev o--A--x--B--x ... Y
Now it turns out that going forward, I need two development branches, one
that's based on a newer version of upstream for which the merge work was
already done in the original dev. In an ideal world I'd have this history:
upstream 1--2--3--4--5
\ \
dev2 \ o--o--o--o
\
dev1 o--o--o--o--o
And I would periodically merge dev1 into dev2 (dev2 requires the work being
done on dev1). The problem is that my backported dev' has a mix of dev1 and
dev2 and it's impossible for me to tease them apart at this point. So my plan
was to do this:
dev' o--A'--B' ... Y'
/ \
upstream 1--2--3--4--5 \
\ \ \ \
dev o--A--x--B--x ... Z
Where Z is created using using "git merge -s ours dev'". Is it correct that
this should do nothing more than give me a new merge base for dev and dev'?
Then going forward I can merge from dev' to dev per usual.
Thanks,
j.
--
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