Re: [PATCH] sequencer.c: abbreviate hashs placed in the middle of messages

[Junio C Hamano <gitster@pobox.com>]

Ralf Thielow <ralf.thielow@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> But I doubt the value of pointing out exact commit in the first
>> place, which leads me to say that "no -m option was given but
>> history has a merge" might be a viable alternative.
>>
>> If identifying the exact commit has value, on the other hand, we can
>> rephrase it like this:
>
> It has value since you see the hash and can check if you have
> passed a wrong commit accidently.

Let's say by mistake I applied your patch while I had 'master'
checked out, and I want to cherry-pick it to its own branch, by
doing something like

    $ git checkout -b rt/sequencer-error-messages maint
    $ git cherry-pick <branch-name-here>

and typed next by mistake instead of master in the above.  I should
get "that commit is a merge but you didn't tell me relative to which
of its parents you want the changes ported".

Does it make it any clearer to say "commit 38e707... is a merge"
compared to "commit you gave me is a merge", with or without
abbreviation?

I do not think so.  I know I said "git cherry-pick next".

> I don't see why you suggest to rephrase the messages over an
> abbreviation of the hash. Is it because I wrote "in the middle of"?

No.

I am merely making sure that the original problem is well analysed
and we looked at other possibilities before picking one, i.e. making
sure that we did not pick the one merely because it happened to be
an expedient thing to do.

And shortening the output feels to me a more expedient thing to do
because we do not have to analyse the ramification of possible
information loss (your "It has value since...").  If we analyse the
issue well, we might realize that there is little point in showing
the commit object name in hexadecimal, be it in full or in shortened
form.

If the proposal were to parrot what the user typed on the command
line, e.g. one of these (or their rephrased versions)

	error: commit 'next' is a merge but no -m option was given.
	error: no -m option was given to pick a merge 'next'.

against the above example, then I would say that would be an
improvement, but that is not what is being discussed, so...