[RFC] Disabling status hints in COMMIT_EDITMSG

[RFC] Disabling status hints in COMMIT_EDITMSG

[Matthieu Moy]

Hi,

I just noticed that the template COMMIT_EDITMSG was containing status
hints, and that they were not particularty helpfull _during_ a commit. I
think it would be sensible to ignore advice.statusHints and disable
hints unconditionally when writting to COMMIT_EDITMSG.

Any objection?

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

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[Chris Packham]

On 10/09/13 21:19, Matthieu Moy wrote:
> Hi,
> 
> I just noticed that the template COMMIT_EDITMSG was containing status
> hints, and that they were not particularty helpfull _during_ a commit. I
> think it would be sensible to ignore advice.statusHints and disable
> hints unconditionally when writting to COMMIT_EDITMSG.
> 
> Any objection?
> 

I did recently find them useful/reassuring when I was committing a
merge. But I wouldn't consider that a strong objection.

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[Matthieu Moy]

Chris Packham <judge.packham@gmail.com> writes:

> On 10/09/13 21:19, Matthieu Moy wrote:
>> Hi,
>> 
>> I just noticed that the template COMMIT_EDITMSG was containing status
>> hints, and that they were not particularty helpfull _during_ a commit. I
>> think it would be sensible to ignore advice.statusHints and disable
>> hints unconditionally when writting to COMMIT_EDITMSG.
>> 
>> Any objection?
>> 
>
> I did recently find them useful/reassuring when I was committing a
> merge. But I wouldn't consider that a strong objection.

Just to make sure we're talking about the same thing: when commiting a
merge, the template currently looks like:

  Merge branch 'master' of /tmp/git
  
  Conflicts:
  	foo.txt
  #
  # It looks like you may be committing a merge.
  # If this is not correct, please remove the file
  #	.git/MERGE_HEAD
  # and try again.
  
  
  # Please enter the commit message for your changes. Lines starting
  # with '#' will be ignored, and an empty message aborts the commit.
  # On branch master
  # Your branch and 'origin/master' have diverged,
  # and have 3 and 1 different commit each, respectively.
  #   (use "git pull" to merge the remote branch into yours)
  #
  # All conflicts fixed but you are still merging.
  #   (use "git commit" to conclude merge)
  #
  # Changes to be committed:
  #
  #	modified:   foo.txt
  #

What I'd like to remove are the parts between parenthesis :

  (use "git commit" to conclude merge)
  (use "git pull" to merge the remote branch into yours)

The first part (It looks like [...]) would remain, of course.

Actually, even the "All conflicts fixed but you are still merging." part
is not really accurate when the commit is already started.

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

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[Chris Packham]

On Tue, Sep 10, 2013 at 11:04 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Chris Packham <judge.packham@gmail.com> writes:
>
>> On 10/09/13 21:19, Matthieu Moy wrote:
>>> Hi,
>>>
>>> I just noticed that the template COMMIT_EDITMSG was containing status
>>> hints, and that they were not particularty helpfull _during_ a commit. I
>>> think it would be sensible to ignore advice.statusHints and disable
>>> hints unconditionally when writting to COMMIT_EDITMSG.
>>>
>>> Any objection?
>>>
>>
>> I did recently find them useful/reassuring when I was committing a
>> merge. But I wouldn't consider that a strong objection.
>
> Just to make sure we're talking about the same thing: when commiting a
> merge, the template currently looks like:
>
>   Merge branch 'master' of /tmp/git
>
>   Conflicts:
>         foo.txt
>   #
>   # It looks like you may be committing a merge.
>   # If this is not correct, please remove the file
>   #     .git/MERGE_HEAD
>   # and try again.
>
>
>   # Please enter the commit message for your changes. Lines starting
>   # with '#' will be ignored, and an empty message aborts the commit.
>   # On branch master
>   # Your branch and 'origin/master' have diverged,
>   # and have 3 and 1 different commit each, respectively.
>   #   (use "git pull" to merge the remote branch into yours)
>   #
>   # All conflicts fixed but you are still merging.
>   #   (use "git commit" to conclude merge)
>   #
>   # Changes to be committed:
>   #
>   #     modified:   foo.txt
>   #
>
> What I'd like to remove are the parts between parenthesis :
>
>   (use "git commit" to conclude merge)
>   (use "git pull" to merge the remote branch into yours)
>
> The first part (It looks like [...]) would remain, of course.
>
> Actually, even the "All conflicts fixed but you are still merging." part
> is not really accurate when the commit is already started.

OK. I wouldn't miss that parts in parenthesis. If I chose to abort the
commit from the editor (e.g. :cq in vi) git status would still tell me
what I need to know.

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

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[Junio C Hamano]

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

> Hi,
>
> I just noticed that the template COMMIT_EDITMSG was containing status
> hints, and that they were not particularty helpfull _during_ a commit. I
> think it would be sensible to ignore advice.statusHints and disable
> hints unconditionally when writting to COMMIT_EDITMSG.
>
> Any objection?

I agree that the extra "this is how you may rectify the situation"
lines like these look useless at the first glance.

    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #       new file:   foo
    #
    # Untracked files:
    #  (use "git add <file>..." to include in what will be committed)
    #
    #       bar
    #

The whole point of showing the list is to give the user a chance to
notice mistakes, and after noticing a mistake, what the user does is
to abort the commit, not "git reset HEAD <file>" nor "git add <file>".

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.

So I am on the fence on this one.  No strong objection, but I
suspect those who do not have any voice in this discussion
(i.e. those who are about to start using Git) may be helped by
keeping these lines.

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[Matthieu Moy]

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". The advice for untracked files is less
counter-productive, but while we're removing the non-sensical ones, I
think it makes sense to remove the essentially-useless ones too.

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

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[Javier Domingo]

IMHO, It is alright as it is.

I have been using git for 4~ years now, and I still find very useful
those lines. They are like a git status while committing, and it's the
key to avoid accidental commits of objects or forgetting files in a
commit. Between that and that the commit message can't be empty, I can
abort a commit and correct the staging area.

Cheers,

Javier Domingo

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[Matthieu Moy]

Javier Domingo <javierdo1@gmail.com> writes:

> IMHO, It is alright as it is.
>
> I have been using git for 4~ years now, and I still find very useful
> those lines. They are like a git status while committing, and it's the
> key to avoid accidental commits of objects or forgetting files in a
> commit.

Having the list of staged/unstaged/untracked is the key to that, and I'm
not planning on changing that. Having advices on how to change it
("run ... to ...") is another matter.

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

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[John Szakmeister]

On Wed, Sep 11, 2013 at 3:24 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> 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". The advice for untracked files is less
> counter-productive, but while we're removing the non-sensical ones, I
> think it makes sense to remove the essentially-useless ones too.

FWIW, I think it makes sense to remove the extra advice too.

-John

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[Javier Domingo]

That extra info doesn't occupy too much, and helps distinguish between
sections. They do also remember you the commands to use (thought after
some time using git, you may not need it).

Cheers,

Javier

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[Junio C Hamano]

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.

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[Matthieu Moy]

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/

Re: [RFC] Disabling status hints in COMMIT_EDITMSG

[Jonathan Nieder]

Matthieu Moy wrote:

> I just noticed that the template COMMIT_EDITMSG was containing status
> hints, and that they were not particularty helpfull _during_ a commit. I
> think it would be sensible to ignore advice.statusHints and disable
> hints unconditionally when writting to COMMIT_EDITMSG.
>
> Any objection?

No objection from me.  It sounds like a good change.

Thanks,
Jonathan