Re: [ANNOUNCE] pg - A patch porcelain for GIT

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Feb 15, 2006, 17:12 UTC
Message-ID: <b0943d9e0602150912h55fb87d0r@mail.gmail.com>
In-Reply-To: <20060214045618.GA12844@spearce.org>

On 14/02/06, Shawn Pearce <spearce@spearce.org> wrote:

> Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > - Automatic detection (and cancellation) of returning patches.

[...]

Show 9 quoted lines

> > StGIT has been doing this from the beginning. You would need to run a
> > 'stg clean' after a rebase (or push). I prefer to run this command
> > manually so that 'stg series -e' would show the empty patches and let
> > me decided what to do with them.
>
> Actually StGIT didn't do this correctly for one of my use cases
> and that's one of the things that drove me to trying to write pg
> (because I wondered if there was a way to resolve it automatically).
> Try building a patch series such as:

[...]

> StGIT seemed to not handle this when it tried to reapply the two
> already applied patches.  A won't apply because the file coming
> down is actually A+B, not A's predecessor and not A.  B won't apply
> because the file also isn't A (B's predecessor).

You are right, if two patches modify the same line and both were merged upstream, the three-way merging would report a conflict for the first patch and maybe the second (depending on how the first conflict was resolved).

Show 5 quoted lines

> pg resolves this by attempting to automatically fold patches during
> a pg-rebase (equiv. of stg pull).  If a patch fails to push cleanly
> and there's another patch immediately behind it which also should
> be reapplied pg aborts and retries pushing the combination of the
> patches.  This fixes my A+B case quite nicely during a rebase.  :-)

But what would happen if there was a third-party patch that's modifying the same line? A+B application would fail in this case. Does pg go back to only apply A and report a conflict?

There is another problem with this approach if you have tens of patches. Would pg try to fold all of them?

Some time ago I had a look at Darcs and its patch theory (patch commuting). Their approach to conflicts was to include the conflicts in patch A and propagate them to the last patch to be merged. It's like creating two versions of the conflicting hunk, one of them corresponding to the local tree (that in patch A) and the other to the upstream tree. Merging patch B is only done in the local hunk in the end both conflicting hunks would be identical and one of them removed.

While the above algrithm seems to work OK in Darcs (but quite resource intensive), it's pretty hard to implement and I don't think it's worth for a small number of cases this could occur.

-- Catalin