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

From: Avery Pennarun <apenwarr@gmail.com>
Date: Feb 3, 2010, 18:57 UTC
Message-ID: <32541b131002031057q866d3q95d0e80a0adf6c52@mail.gmail.com>
In-Reply-To: <76c5b8581002031049t5558a700qe2e05bb70d175305@mail.gmail.com>

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

Show 7 quoted lines

> OK. I admit I got confused with the fact that some editors (vi,
> kwrite, gedit - i just tested them to be 100% sure) do allow you to
> hit save right after the file was opened and the timestamp will be
> changed, while emacs or open office writer or some others do not, if
> no changes has been made. Therefore there is no way to actually change
> the timestamp on the file from editors like emacs without actually
> changing something.

Of course, in such editors you could just hit "space; backspace" and then save. Sounds annoying? Well, so does deleting all the lines in the commit message just to make it *not* amend.

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.

But you can't just blindly change the system to always work in a different way. People depend on the current behaviour. Jeff King's script is a pretty cute solution that lets you have it your way with no changes to git, though.

Of course, this does open up the question of how to do any global UI design at all if a decision made once gets locked in forever. The reason git is hard for new users is that its UI is crazy and confusing, but a major reason it keeps gaining in popularity is that once you learn git, you stick with it, because you don't have to relearn it with every new version.

Have fun,

Avery