Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> Being in an editor but still not able to fix typos is a nuisance.
>
> NAK.
>
> Supporting that would be totally out of line with the way rebase -i is
> supposed to work.
If the rebase insn sheet were richer, and had a way to show the full
message, like this:
pick 4973aa2 git-pull: dead code removal
Back when a74b170 (git-pull: disallow implicit merging to detached HEAD,
2007-01-15) added this check, $? referred to the error status of reading
HEAD as a symbolic-ref; but cd67e4d (Teach 'git pull' about --rebase,
2007-11-28) moved the command away from where the check is, and nobody
noticed the breakage. Ever since, $? has always been 0 (tr at the end of
the pipe to find merge_head never fails) and other case arms were never
reached.
These days, error_on_no_merge_candidates function is prepared to handle a
detached HEAD case, which was what the code this patch removes used to
handle.
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
I do not see why we shouldn't allow people to edit any part of the above
to reword.
I would even understand (but not necessarily agree) if somebody wants to
give the patch text and let users edit to reapply.
So I do not agree with your "totally out of line" at all.
> Besides, if you already have typos in the commit subject, you _better_
> check the whole commit message, so: double NAK.
That sounds a bit too dogmatic.
But I tend to agree with you that we would be better off not accepting
such a "retitle" patch, as it strongly encourages single-liner commit log
messages.
Oh, there was no patch? Then nevermind...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html