From: Catalin Marinas <catalin.marinas@gmail.com>
To: git@vger.kernel.org
Subject: Re: [ANNOUNCE] pg - A patch porcelain for GIT
Date: Wed, 15 Feb 2006 17:12:55 +0000 [thread overview]
Message-ID: <b0943d9e0602150912h55fb87d0r@mail.gmail.com> (raw)
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.
[...]
> > 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).
> 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
next prev parent reply other threads:[~2006-02-15 17:13 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-10 19:59 [ANNOUNCE] pg - A patch porcelain for GIT Shawn Pearce
2006-02-10 20:41 ` Greg KH
2006-02-10 21:04 ` Shawn Pearce
2006-02-10 23:20 ` Greg KH
2006-02-10 21:17 ` Petr Baudis
2006-02-10 21:38 ` Shawn Pearce
2006-02-10 21:47 ` Petr Baudis
2006-02-10 22:07 ` Junio C Hamano
2006-02-13 21:00 ` Petr Baudis
2006-02-14 9:26 ` Catalin Marinas
2006-02-14 10:08 ` Karl Hasselström
2006-02-14 15:22 ` Chuck Lever
2006-02-14 16:07 ` Karl Hasselström
2006-02-14 20:58 ` Chuck Lever
2006-02-14 22:29 ` Petr Baudis
2006-02-15 0:22 ` Sam Vilain
2006-02-15 0:35 ` Shawn Pearce
2006-02-15 1:14 ` Petr Baudis
2006-02-15 4:11 ` J. Bruce Fields
2006-02-15 6:54 ` Shawn Pearce
2006-02-15 19:45 ` J. Bruce Fields
2006-02-16 10:24 ` Junio C Hamano
2006-02-16 10:33 ` Catalin Marinas
2006-02-16 10:42 ` Fernando J. Pereda
2006-02-16 10:52 ` Junio C Hamano
2006-02-16 11:10 ` Catalin Marinas
2006-02-15 17:25 ` Catalin Marinas
2006-02-16 7:54 ` Karl Hasselström
2006-02-17 4:27 ` [PATCH 0/2] stg uncommit Karl Hasselström
2006-02-17 4:31 ` [PATCH 1/2] Update .git/refs/heads/base after patch deletion Karl Hasselström
2006-02-17 4:31 ` [PATCH 2/2] Add 'stg uncommit' command Karl Hasselström
2006-02-19 10:51 ` Catalin Marinas
2006-02-19 13:45 ` Karl Hasselström
2006-02-19 14:47 ` Karl Hasselström
2006-02-19 21:15 ` Sam Vilain
2006-02-20 17:20 ` Catalin Marinas
2006-02-20 17:30 ` Karl Hasselström
2006-02-20 22:49 ` Catalin Marinas
2006-02-21 7:55 ` Karl Hasselström
2006-02-15 10:11 ` [ANNOUNCE] pg - A patch porcelain for GIT Karl Hasselström
2006-02-15 10:42 ` Andreas Ericsson
2006-02-15 11:25 ` Karl Hasselström
2006-02-15 11:27 ` Karl Hasselström
2006-02-17 21:57 ` Catalin Marinas
2006-02-13 2:49 ` Sam Vilain
2006-02-13 3:29 ` Shawn Pearce
2006-02-13 4:40 ` Sam Vilain
2006-02-13 6:03 ` Shawn Pearce
2006-02-13 14:40 ` Catalin Marinas
2006-02-14 4:56 ` Shawn Pearce
2006-02-14 6:14 ` Shawn Pearce
2006-02-15 17:20 ` Catalin Marinas
2006-02-15 17:12 ` Catalin Marinas [this message]
2006-02-15 17:55 ` Shawn Pearce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b0943d9e0602150912h55fb87d0r@mail.gmail.com \
--to=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).