From: Peter Osterlund <petero2@telia.com>
To: Catalin Marinas <catalin.marinas@gmail.com>
Cc: GIT <git@vger.kernel.org>
Subject: Re: Stacked GIT 0.3 (now more Quilt-like)
Date: 03 Jul 2005 14:38:55 +0200 [thread overview]
Message-ID: <m3oe9k6p40.fsf@telia.com> (raw)
In-Reply-To: <1120385280.6845.12.camel@localhost.localdomain>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> Hi Peter,
>
> Thanks for trying this tool.
>
> On Sun, 2005-07-03 at 10:38 +0200, Peter Osterlund wrote:
> > This is good stuff and the 3-way merge really simplifies things.
> > However, if there is a merge conflict, you will basically be stuck
> > with a 2-way merge when resolving manually. It's usually much easier
> > if you can see all three version, so I think it's better to use -A
> > instead of -E in the diff3 command.
>
> I know that using -A gives a more detailed output in case of a conflict.
> The problem is that you will get a conflict even if the changes are
> identical, making it impossible to detect when a patch was merged
> upstream.
OK, I see. How about using wiggle instead?
http://cgi.cse.unsw.edu.au/~neilb/source/wiggle/
That's what patch-utils uses if you run "pushpatch -m". wiggle is also
a lot smarter than diff3, so there will be fewer cases that result in
a conflict. Maybe a parameter to "stg push" could enable wiggle mode.
Another nice thing from patch-utils is that if applying the patch
would have failed, nothing will be done by "pushpatch". You then have
the option to rerun it with -m (merge) or -f (force, create .rej
files), or decide that you don't want to push the patch at all. The
last part is quite useful if you try to reorder a patch series, find
out that you would get a thousand conflicts, and want to reconsider.
Is there a way in StGIT to undo a push that results in a large mess of
conflicts?
> Speaking of detecting upstream merges, the latest StGIT snapshot shows a
> '0' in front of a patch if it is empty, when 'stg series' is invoked.
> When pushing, if all the changes are the same, it notifies you that the
> patch is empty so that it can be safely removed.
That's a useful feature. With patch-utils, I used to drop patches
manually, but that could lose information if the patch applied
upstream is not exactly the same as the one I had locally.
--
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340
next prev parent reply other threads:[~2005-07-03 12:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-28 21:26 Stacked GIT 0.3 (now more Quilt-like) Catalin Marinas
2005-07-03 8:38 ` Peter Osterlund
2005-07-03 10:08 ` Catalin Marinas
2005-07-03 12:38 ` Peter Osterlund [this message]
2005-07-03 21:14 ` Catalin Marinas
2005-07-04 1:10 ` Horst von Brand
2005-07-04 6:27 ` Martin Langhoff
2005-07-04 12:32 ` Peter Osterlund
2005-07-04 17:09 ` randy_dunlap
2005-07-04 20:42 ` Catalin Marinas
2005-07-06 20:54 ` Catalin Marinas
2005-07-07 19:17 ` Peter Osterlund
2005-07-07 21:22 ` Catalin Marinas
2005-07-08 1:10 ` Peter Osterlund
2005-07-08 1:24 ` Junio C Hamano
2005-07-08 8:14 ` Peter Osterlund
2005-07-08 9:32 ` Catalin Marinas
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=m3oe9k6p40.fsf@telia.com \
--to=petero2@telia.com \
--cc=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.
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).