From: Charles Bailey <charles@hashpling.org>
To: Jeff King <peff@peff.net>
Cc: William Pursell <bill.pursell@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] feature request: git-mergetool --force
Date: Sun, 19 Oct 2008 00:16:37 +0100 [thread overview]
Message-ID: <48FA6E55.9030101@hashpling.org> (raw)
In-Reply-To: <20081018205443.GA29534@coredump.intra.peff.net>
Jeff King wrote:
> On Sat, Oct 18, 2008 at 07:44:47PM +0100, William Pursell wrote:
>
>>> Something like --no-prompt makes more sense to me, though probably
>>> something a little easier to type would be nice (or maybe alias "-n").
>> Actually, perhaps an "interactive=no" configuration setting,
>> which might imply trustExitCode = true.
>
> That sounds reasonable to me.
>
> -Peff
I've recently been using git mergetool quite a bit and I'm currently
cooking a couple of patches. The first, by coincidence, was a "-n"
option which disabled the hit-return-to-actually-do-anything prompt. I,
also, used the variable "NOPROMPT" to describe this behaviour.
The other change that I am working was more of an issue for me. When I
have a fair number of files to merge I sometimes want to skip a merge.
Perhaps it's a tricky one and I want do the easy wins first.
The current behaviour of mergetool is a little annoying for this as the
first 'failed' merge aborts the process and if you restart it will
always pick up from where it left off. If you want to do some of the
later files, you have to specify the full paths to mergetool which can
be a lot more typing.
The change I am implementing just continues after a failed merge (no git
add or anything, so the file stays unmerged) and allows you to merge
subsequent files. I think that this will work reasonably well allowing
you to do your merges in a number of passes, picking off the easy merges
first and doing the tricky ones later. You can also do a quick pass
through all the merges, not actually resolving everything just to see if
there are any show stoppers.
The only gotcha is that this may interact less well with a --no-prompt
option. With the prompt you can always abort the mergetool process with
a SIGINT at the prompt, even if mergetool now wants to offer you the
opportunity to merge subsequent files after aborting one particular file
merge. Without the prompt mergetool is going to spawn your merge tool
for every conflict even if you've changed your mind and want to abort.
Thoughts?
Charles.
next prev parent reply other threads:[~2008-10-18 23:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-17 23:23 [PATCH] feature request: git-mergetool --force William Pursell
2008-10-18 15:48 ` Jeff King
2008-10-18 18:44 ` William Pursell
2008-10-18 20:54 ` Jeff King
2008-10-18 23:16 ` Charles Bailey [this message]
2008-10-19 11:47 ` Jeff King
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=48FA6E55.9030101@hashpling.org \
--to=charles@hashpling.org \
--cc=bill.pursell@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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).