From: Eugene Sajine <euguess@gmail.com>
To: Avery Pennarun <apenwarr@gmail.com>
Cc: Wincent Colaiuta <win@wincent.com>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
kusmabite@gmail.com,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Jacob Helwig <jacob.helwig@gmail.com>,
git@vger.kernel.org
Subject: Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
Date: Wed, 3 Feb 2010 14:27:16 -0500 [thread overview]
Message-ID: <76c5b8581002031127m31c39dbbkc7c31d19e4d5874@mail.gmail.com> (raw)
In-Reply-To: <32541b131002031057q866d3q95d0e80a0adf6c52@mail.gmail.com>
> 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.
That was exactly the starting point of my thoughts.Currently it forces
user to be explicit if he wants to cancel the operation (rebase -i,
or amend), instead of forcing user to be explicit to proceed.
>
> 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.
> Jeff King's script is a pretty cute solution that lets you have it your way with
> no changes to git, though.
Thanks to Jeff, I'll try it.
>
> 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.
100% agree, there is such question.
> 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.
I just didn't realize that this can be such a drastic change for users
as well as technical difficulties related to the emacs and similar
editors.
Thanks,
Eugene
next prev parent reply other threads:[~2010-02-03 19:27 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-02 20:07 [BUG] - "git commit --amend" commits, when exiting the editor with no changes written Eugene Sajine
2010-02-02 20:14 ` Jacob Helwig
2010-02-02 20:27 ` Avery Pennarun
2010-02-02 20:47 ` Eugene Sajine
2010-02-02 20:58 ` Wincent Colaiuta
2010-02-02 21:56 ` Eugene Sajine
2010-02-02 22:03 ` Erik Faye-Lund
2010-02-02 22:06 ` Wincent Colaiuta
2010-02-02 22:31 ` Eugene Sajine
2010-02-02 22:35 ` Avery Pennarun
2010-02-02 23:02 ` Eugene Sajine
2010-02-02 23:15 ` Johannes Schindelin
2010-02-02 23:27 ` Eugene Sajine
2010-02-02 23:40 ` Avery Pennarun
2010-02-03 6:15 ` Larry D'Anna
2010-02-03 9:31 ` Jeff King
2010-02-03 10:15 ` Jeff King
2010-02-03 18:19 ` Avery Pennarun
2010-02-02 23:00 ` Johannes Schindelin
2010-02-02 23:34 ` Eugene Sajine
2010-02-02 23:40 ` Erik Faye-Lund
2010-02-02 23:48 ` Eugene Sajine
2010-02-03 0:16 ` Erik Faye-Lund
2010-02-03 0:55 ` Eugene Sajine
2010-02-03 1:59 ` SZEDER Gábor
2010-02-03 7:34 ` Matthieu Moy
2010-02-03 9:08 ` aborting rebase -i right at the start, was " Johannes Schindelin
2010-02-03 9:41 ` SZEDER Gábor
2010-02-03 16:02 ` Eugene Sajine
2010-02-03 7:31 ` Matthieu Moy
2010-02-03 15:45 ` Eugene Sajine
2010-02-03 17:51 ` Jonathan Nieder
2010-02-03 17:53 ` Jonathan Nieder
2010-02-03 18:21 ` Wincent Colaiuta
2010-02-03 18:49 ` Eugene Sajine
2010-02-03 18:57 ` Avery Pennarun
2010-02-03 19:27 ` Eugene Sajine [this message]
2010-02-03 19:54 ` Avery Pennarun
2010-02-03 18:47 ` Matthieu Moy
2010-02-02 23:58 ` Johannes Schindelin
2010-02-03 0:09 ` Eugene Sajine
2010-02-03 9:04 ` Johannes Schindelin
2010-02-03 9:46 ` Paolo Bonzini
2010-02-02 23:44 ` Junio C Hamano
2010-02-02 21:18 ` Avery Pennarun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76c5b8581002031127m31c39dbbkc7c31d19e4d5874@mail.gmail.com \
--to=euguess@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=jacob.helwig@gmail.com \
--cc=kusmabite@gmail.com \
--cc=win@wincent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).