All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: git <git@vger.kernel.org>
Subject: Re: [RFC] Disabling status hints in COMMIT_EDITMSG
Date: Wed, 11 Sep 2013 10:24:00 -0700	[thread overview]
Message-ID: <xmqqob7ztgpb.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <vpq61u7akin.fsf@anie.imag.fr> (Matthieu Moy's message of "Wed, 11 Sep 2013 09:24:16 +0200")

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> But at the same time, I feel that these redundant lines, especially
>> the latter one, would give the users a stronger cue than just saying
>> that "bar is Untracked"; "do X to include" reminds that bar will not
>> be included if nothing is done.
>
> The one which draw my attention was "(use "git commit" to conclude
> merge)" which is particularly counter-productive when you are already
> doing a "git commit".

Oh, no question about that.  Nobody would object to the removal of
that one; it is clearly nonsense.

I was commented on the value of keeping "hints" like this:

      # Untracked files:
      #   (use "git add <file>..." to include in what will be committed)

The primary value of the hint in the context of commit message
buffer *NOT* being "what exactly do I need to do after I abort this
commit?", but being "Ahh, this 'Untracked' section is showing me
files that I may have forgotten to 'git add'".  If new users do not
benefit from the latter, I am perfectly fine with the removal, but I
suspect it may not be the case, hence my earlier comment.

And "the user can see these hints by running another 'git status'
after aborting the commit anyway" is an irrelevant counter-argument,
exactly because my point is that I suspect having them in the commit
template comment may help the users to *decide* if they want to
continue with or abort the commit.

But as I said already, I do not have a strong preference either way.

Will queue the two patches (but I see there are already some obvious
fixes suggested).

Thanks.

  parent reply	other threads:[~2013-09-11 17:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-10  9:19 [RFC] Disabling status hints in COMMIT_EDITMSG Matthieu Moy
2013-09-10  9:53 ` Chris Packham
2013-09-10 11:04   ` Matthieu Moy
2013-09-10 21:11     ` Chris Packham
2013-09-10 16:42 ` Junio C Hamano
2013-09-11  7:24   ` Matthieu Moy
2013-09-11  7:42     ` Javier Domingo
2013-09-11  8:05       ` Matthieu Moy
2013-09-11  9:14     ` John Szakmeister
2013-09-11 14:03       ` Javier Domingo
2013-09-11 17:24     ` Junio C Hamano [this message]
2013-09-11 17:40       ` Matthieu Moy
2013-09-10 18:03 ` Jonathan Nieder

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=xmqqob7ztgpb.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.