Re: Testing git-debrebase/dgit in the linux git repo

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Ben Hutchings writes ("Re: Testing git-debrebase/dgit in the linux git repo"):
> git-debrebase(5) goes into more detail about this.  Basically it
> doesn't work after any merge commit where the new tree is not identical
> to one of the parents.  So a merge from master to sid would be OK (the
> result should match master even if it's not fast-forward) but a merge
> in the other direction would not.  But worse than that, a non-fast-
> forward merge from a remote tracking branch to the corresponding local
> branch would also break it.
> 
> So I can't see how git-debrebase is usable for team-maintained packages
> yet.  A "git pull" that merges is not safe, and a "git pull" that
> rebases is also not safe because you must use "git debrebase" for all
> rebases.
> 
> I thought I was told that team maintenance should be OK.  Did I
> misunderstand?  Am I missing something?

How big a problem this is depends how much your team works in
parallel.

I do have some experimental support for merge resolution.  It ought to
deal reasonably well with cases where what has been merged is the
packaging, rather than the delta queues.  Ie, if only one side has
edited the patch queue.  It'll probably also cope well with addition
of independent new upstream-files commits to the end of the delta
series.

If it can't cope because both sides edited the delta queues in a way
it can't cope with, leaves a pile of refs containing pieces of the
wreckage, which an expert could fix up.

If you want to try this out on some actual existing merges in your
existing history, you can do it by passing
  --experimental-merge-resolution
on the command line.  If this is successful it will generate a merge
commit in your breakwater which new enough git-debrebase should be
willing to recognise and not try to rewrite, even without that option.

There are other options for resolving this kind of thing, including
using `git pull --rebase' more often, but they are also not
brilliant.

Anticipating this question is why I wrote the merge support but I have
not yet found anyone who needed it.  So as a result I don't know how
well it works in practice.

Nor do I know what the best way to handle failed delta queue merges
is.  Internally right now the algorithm tries to: identify a common
upstream commit; use gbp pq to convert each delta queue as patches;
use git merge to merge the patches textually; use a sort of graph
theory like algorithm to merge the series files; and apply the result
to the identified upstream.  If this all works then it's pretty
seamless.

If it doesn't work the most obvious reason is patch queue merge
failure, or application failure, which you can fix up by checking out
the wreckage refs, wrestling with conflicts in diff files or whatever,
and eventually telling gdr about an appropriate resolution.

I think in the general case merging delta queues looks something like
this example [1]

      Ul--1-2'-3"-4-5       Ul
     /                     /  \
   Ub---1-2-3        +   Ub    Um    =>   Um--2??-5-9-3"'-4-8
     \                     \  /
      Ur--5-9-3'-8          Ur

and this is (a) horrid (b) an open research problem.

I don't even know of a really good way to present a problem like this
to the user, so the tool can say "you guys did a crazy thing pls fix".

I hope this is illuminating.  If you want to try this merge feature I
think you'd be the first user and I would be happy to ... give you
fairly intensive support :-).

Regards,
Ian.

[1] Ul, Ur, Ub are the left right and base upstreams; Um is some
merged upsream which someone presumably supplies.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.