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

Junio C Hamano <gitster@pobox.com> writes:

> 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)

Yes, I understood your argument.

I have no strong opinion on whether they should be removed either, but I
went for the removal essentially because it keeps the code simple.

If we want to keep the advices, and if we want them to be really sound,
then for example the advice for "Changes to be committed:" should be
changed when running "git commit --amend" (we currently hint "git reset"
even for files which are not in the index in this case). Same for
--only/--include. So, giving accurate hints in all cases seems
non-trivial.

I think the value of these messages is smaller than the potential
confusion and/or the code complexity to select and possibly modify the
hints.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

  reply	other threads:[~2013-09-11 17:43 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
2013-09-11 17:40       ` Matthieu Moy [this message]
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=vpqfvtb5k9y.fsf@anie.imag.fr \
    --to=matthieu.moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 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.