Jay Soffian <jaysoffian@xxxxxxxxx> writes:
> 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
I understand that at this point "dev'" is the moral equivalent of what you
called "dev1" in the next picture.
> upstream 1--2--3--4--5
> \ \
> dev2 \ o--o--o--o
> \
> dev1 o--o--o--o--o
It is unclear what commits on dev2 branch are about in this picture. Are
they replay of what you have on dev1? Or are they about a feature that is
different from what dev1 does, perhaps using what dev1 have already done,
or perhaps totally independent of dev1?
If "dev1" and "dev'" are the moral equivalents, and dev2 wants to use what
dev1 did _and_ what is in updated upstream (i.e. dev2 cannot build without
either dev1 nor some of the feature/fix in "2"..."5"), then I would
probably build a history that looks like this:
o--o--o dev2 (builds on top of dev1)
/
.--* merge between dev1 and upstream
/ /
o--o--o--o / dev1
/ /
1--2--3--4--5 upstream
and give a pull request to the upstream for "*" to incorporate the fully
cooked work done on dev1.
Also if "dev'" and "dev1" are the moral equivalents, then the merge "*"
above _should_ match exactly what you had at "Y" in "dev" in the original
mergy history. So after creating "*", you may want to do a regular merge
(IOW, I don't think "-s ours" is necessary if you rebuilt "dev1" right)
between it and 'dev' to create "M" that should result in the same tree:
.--* merge between dev1 and upstream
/ / \
o--o--o--o / \ dev1
/ / \
1--2--3--4--5 \ upstream
\ \ \ \
o--A--x--B--x-..-Y--M dev
\
o--o--o dev2'
and build "dev2'" on "dev" instead; but you probably cannot offer "dev" to
be pulled to the upstream due to the criss-cross mess (that was the whole
reason you did "dev1" in the first place), and doing so would make "dev2'"
unpullable for the same reason. So I don't see much point in doing that
merge "M" nor keeping "dev" branch around, once you verified that "*" and
"Y" matches to make sure your rebuilt dev1 has what dev has, and it is
what dev should have looked like in the first place.
If you want to keep merging from dev1 to dev2 because dev1 is still not
ready, you might want to choose to rebase dev2 on top of dev1 instead.
--
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