Hi.
I'm going to reply off the cuff in the hope of getting you unstuck.
If this email doesn't nsuffice I'll take a look at your git
branch. So please let me know how you get on.
Philipp Kern writes ("Bug#1059388: git-debrebase: found two-parent merge, how
to cope?"):
> In the absence of a better venue of asking this question (there seems to
> be no mailing list): I have an upstream repository that contains a
> two-parent merge for some reason (https://github.com/twosigma/nsncd, of
> all the things merging a CLA into the repository). dgit bails out with
> this:
In git-debrebase, the upstream branches are supposed to be able to
contain any arbitrary stuff.
gdr is supposed to stop looking in detail at the commit structure as
soon as it finds the anchor, ie the last merge from into Debian.
These must all be done with gdr new-upstream.
> | Format `3.0 (quilt)', need to check/update patch stack
> | examining quilt state (multiple patches, linear mode)
..
> | git-debrebase: error: found unprocessable commit, cannot cope: general
> two-parent merge (e3de17c274315bab561664ac57e46472670545cf)
I suspect that the upstream branch has been merged directly into your
packaging branch, rather than using git-debrebase --new-upstream ?
> I have so far forced an --anchor manually upon git-debrebase, which
> worked, but is also very tedious to pass everywhere. Is this something
> that will auto-fix itself on the next upstream release because dgit will
> properly discard the history pre the current upstream release? I was at
> least hoping that it would disappear with the first regular upload - but
> this did not happen.
..
> Is there something I can do for dgit to accept the current state of the
> repository as canonical up to the point where the Debian packaging was
> modified/forked off. The snags are upstream's prior packaging as found
> in the upstream repository, which does not seem to be uncommon to me
> either.
I'm not sure using --anchor is wise. Certainly not routinely.
new-upstream would generate a new anchor, so you could use --anchor
once, assuming you're sure about which commit it is.
But if you merged from upstream *on top* of commits represending the
delta, that won't do the right thing. It will abolish the delta and
start to try to treat them as part of the upstream, and then your next
attempt to make a source package will fail.
One thing you could try would be an invocation of
git-debrebase --experimental-merge-resolution new-upstream
Or indeed
git-debrebase --status
I think if my hypothesis about what has happened to your branch is
correct, my suggested remedy would be to make a new branch starting
just before the mistake, redo all subsequent work "properly" - without
introduce any merges other than via git-debrebase new-upstream.
Then when you have done that the result should be tressame to your
"messed up" branch, but have correct gdr history.
Then "git merge -s ours broken-branch" will make your fixed version ff
from the broken one and from then I hope everything will be fine?
(Maybe I should look up which branch of a completely tree-identical
merge gdr looks at, but I'm hoping that it's the one that is implied
by following the non-contributing parent of git merge -s ours.)
Don't spend too long on wrestling with this. I can probably fix it up
in an hour or so.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
