Re: [PATCH] Teach 'rebase -i' the command "amend"

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 5, 2009, 21:07 UTC
Message-ID: <7vbpkl8s8x.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0910052248500.4985@pacific.mpi-cbg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 6 quoted lines

>> 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@pobox.com>

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