git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Andrew Wong <andrew.kw.w@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [RFC 2/3] merge: Add hints to tell users about "git merge --abort"
Date: Wed, 05 Mar 2014 10:29:45 -0800	[thread overview]
Message-ID: <xmqqa9d4ijmu.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CADgNjak3aqPDV0iZYc8b6QJ9y+6bUd28n0UJOm6WjufQhjfuwA@mail.gmail.com> (Andrew Wong's message of "Wed, 5 Mar 2014 10:30:40 -0500")

Andrew Wong <andrew.kw.w@gmail.com> writes:

> On Wed, Feb 26, 2014 at 3:38 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Andrew Wong wrote:
>>
>>> --- a/builtin/merge.c
>>> +++ b/builtin/merge.c
>>> @@ -909,7 +909,8 @@ static int suggest_conflicts(int renormalizing)
>>>       fclose(fp);
>>>       rerere(allow_rerere_auto);
>>>       printf(_("Automatic merge failed; "
>>> -                     "fix conflicts and then commit the result.\n"));
>>> +                     "fix conflicts and then commit the result.\n"
>>> +                     "To abort the merge, use \"git merge --abort\".\n"));
>>
>> Seems reasonable, but I worry about the command growing too noisy.
>>
>> Could this be guarded by an advice.<something> setting?  (See advice.*
>> in git-config(1) for what I mean.)
>
> I was planning to use advice.resolveConflict, but as I went through
> merge.c, I noticed there could be a few other situations where we
> could print out the same message:
> 1. when prepare_to_commit() fails, due to hook error, editor error, or
> empty commit message
> 2. "git commit --no-commit"
>
> This means contexts are no longer only about "resolving conflict", so
> I was thinking of renaming advice.resolveConflict to something like
> advice.mergeHints.
>
> Any thoughts?

I have no strong opinion on the naming, other than that I doubt this
particular new "how to abort" message is worth the headache associated
with the "rename" which involves transition planning of deprecating
the old, supporting both for a while and then removing the old.

The existing message above in "suggest-conflicts" is about hinting
the user to first resolve the conflict before attempting to
continue, and that is perfectly in line with the existing use of
advice.resolveConfict in die_conflict() in git-pull that tells the
user there is an unresolved conflict.

On the other hand, the additional "how to abort" message does not
have to be limited to "you have conflicted paths in the index" case.

If the user said "git merge" while another "git merge" is still
outstanding, we would want to say "You have not concluded your
previous merge" and die, and you presumably want to add the same
"how to abort" message there.  Such a codepath is unlikely to be
covered by existing advice.resolveConflict, and it sounds more
natural, at least to me, to use a separate variable to squelch only
the new "how to abort" part.

  reply	other threads:[~2014-03-05 18:30 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26 18:06 [RFC 0/3] Make git more user-friendly during a merge conflict Andrew Wong
2014-02-26 18:06 ` [RFC 1/3] wt-status: Make conflict hint message more consistent with other hints Andrew Wong
2014-02-26 20:34   ` Jonathan Nieder
2014-02-26 20:37   ` Junio C Hamano
2014-02-26 23:07     ` Andrew Wong
2014-02-26 18:06 ` [RFC 2/3] merge: Add hints to tell users about "git merge --abort" Andrew Wong
2014-02-26 20:38   ` Jonathan Nieder
2014-02-26 23:16     ` Andrew Wong
2014-03-05 15:30     ` Andrew Wong
2014-03-05 18:29       ` Junio C Hamano [this message]
2014-03-05 20:51         ` Andrew Wong
2014-03-05 21:20           ` Junio C Hamano
2014-03-05 18:35       ` Matthieu Moy
2014-02-26 18:06 ` [RFC 3/3] reset: Change the default behavior to use "--merge" during a merge Andrew Wong
2014-02-26 18:21   ` Matthieu Moy
2014-02-26 20:15     ` Andrew Wong
2014-02-26 20:48       ` Jonathan Nieder
2014-02-26 23:37         ` Andrew Wong
2014-02-26 20:57       ` Matthieu Moy
2014-02-27  0:00         ` Andrew Wong
2014-02-26 20:53     ` Junio C Hamano
2014-03-11  4:39       ` Andrew Wong
2014-02-26 20:26 ` [RFC 0/3] Make git more user-friendly during a merge conflict Jonathan Nieder
2014-02-28  9:01   ` Stephen Leake
2014-02-28  9:14     ` Charles Bailey
2014-02-28 10:11     ` David Kastrup
2014-02-28 14:13       ` Stephen Leake
2014-02-28 14:21         ` David Kastrup
2014-02-28 17:26           ` Stephen Leake
2014-02-28 17:33             ` David Kastrup
2014-03-01 10:32               ` Stephen Leake
2014-03-01 11:38                 ` Matthieu Moy
2014-03-01 16:50                   ` Stephen Leake

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=xmqqa9d4ijmu.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=andrew.kw.w@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.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.
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).