git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@gmail.com>
To: "Karl Hasselström" <kha@treskal.com>
Cc: git <git@vger.kernel.org>
Subject: Re: bug?: stgit creates (unneccessary?) conflicts when pulling
Date: Mon, 27 Feb 2006 22:17:00 +0000	[thread overview]
Message-ID: <44037A5C.6080409@gmail.com> (raw)
In-Reply-To: <20060227204252.GA31836@diana.vm.bytemark.co.uk>

Karl Hasselström wrote:
> If I make a patch series where more than one patch touches the same
> line, I get a lot of merge errors when upstream has accepted them and
> I try to merge them back.

We discussed about this in the thread announcing pg
(http://article.gmane.org/gmane.comp.version-control.git/16247). This is
not easy to fix because StGIT pushes patches one by one and it stops at
the first conflict. Pg was trying to merge two patches at once but this
is not suitable for StGIT since the latter keeps the patches as single
commits.

There is another problem - the same line might have been modified by a
third-party patch merged into the kernel (and the conflict solved by the
maintainer).

> This situation arises for every line that's modified in more than one
> patch, and for every such patch except the last one. And it's really
> annoying, since it's intuitively obvious that there aren't actually
> any conflicts, since upstream accepted my patches verbatim.

Because I found the same situation a bit annoying, I added the --reset
option to resolved. If you know your patch was merged without
modifications, just use "stg resolved --all --reset local".

An idea (untested, I don't even know whether it's feasible) would be to
check which patches were merged by reverse-applying them starting with
the last. In this situation, all the merged patches should just revert
their changes. You only need to do a git-diff between the bottom and the
top of the patch and git-apply the output (maybe without even modifying
the tree). If this operation succeeds, the patch was integrated and you
don't even need to push it. The tool could even fold two consecutive
patches and reverse-apply them. The disadvantage might be the delay when
pushing patches but we could enable this test only if an option is
passed to the pull command.

If you really want to make StGIT behave intelligently, have a look at
the patch commuting theory in Darcs. It tends to handle this kind of
conflicts easily. StGIT also does some patch commuting but using the
diff3 algorithm and asks the user to fix different conflicts.

Catalin

  parent reply	other threads:[~2006-02-27 22:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-27 20:42 bug?: stgit creates (unneccessary?) conflicts when pulling Karl Hasselström
2006-02-27 21:45 ` Sam Vilain
2006-02-27 22:17 ` Catalin Marinas [this message]
2006-02-28 15:00   ` Catalin Marinas
2006-02-28 18:53     ` Catalin Marinas
2006-02-28 22:45   ` Catalin Marinas
2006-03-01 17:39     ` Chuck Lever
2006-03-01 17:53       ` Catalin Marinas
2006-03-03 14:13         ` Karl Hasselström
2006-03-03 21:57           ` Catalin Marinas
2006-03-03 14:24     ` Karl Hasselström
2006-03-03 22:07       ` Catalin Marinas
2006-02-27 22:26 ` Shawn Pearce
2006-03-01 10:59   ` Catalin Marinas
2006-03-01 14:51     ` Shawn Pearce
2006-03-01 15:08       ` Catalin Marinas
2006-03-01 15:50         ` Shawn Pearce
2006-03-09 22:00           ` Catalin Marinas
2006-03-09 23:20             ` Junio C Hamano
2006-03-10 11:13               ` Catalin Marinas
2006-03-11  6:46                 ` Junio C Hamano
2006-03-10 16:23             ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44037A5C.6080409@gmail.com \
    --to=catalin.marinas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kha@treskal.com \
    /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.
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 NNTP newsgroup(s).