Re: [PATCH] sequencer.c: abbreviate hashs placed in the middle of messages
From: Junio C Hamano <hidden>
Date: 2016-06-15 23:04:41
Ralf Thielow [off-list ref] writes:
Junio C Hamano [off-list ref] wrote:quoted
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...