Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written

From: Avery Pennarun <apenwarr@gmail.com>
Date: Feb 3, 2010, 19:54 UTC
Message-ID: <32541b131002031154o2146aa05k1065f7bb2d4139dc@mail.gmail.com>
In-Reply-To: <76c5b8581002031127m31c39dbbkc7c31d19e4d5874@mail.gmail.com>

On Wed, Feb 3, 2010 at 2:27 PM, Eugene Sajine <euguess@gmail.com> wrote:

Show 16 quoted lines

>> To reiterate what I said earlier: the mtime idea isn't even
>> automatically a bad one.  It's about as good as what currently exists,
>> and the resulting rule (file content or mtime must be modified) is
>> just as consistent as the current rule (file must be nonempty).  It's
>> also arguably easier for new users to understand.
>
> OK. Agree on that.
>
>> But you can't just blindly change the system to always work in a
>> different way.  People depend on the current behaviour.
>
> I understand that pretty well. My logic is that the most used command
> which is affecting the three is "git commit", therefore this command
> workflow is pretty natural for all users, but the workflow of commit
> --amend and rebase -i which are also affecting the three is
> inconsistent with commit. The user interaction is not the same.

You can't agree with my first statement above and yet still call the commit --amend behaviour inconsistent with normal commit behaviour. It is 100% consistent, as others have already pointed out. Whether it is consistent is not the problem. Your insistence on that point is what's making people argue with you and is undermining your real point.

Have fun,

Avery