From: Avery Pennarun <apenwarr@gmail.com>
To: Eugene Sajine <euguess@gmail.com>
Cc: Wincent Colaiuta <win@wincent.com>,
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: Tue, 2 Feb 2010 18:40:49 -0500 [thread overview]
Message-ID: <32541b131002021540g7a2834c9hacf2be5962f66515@mail.gmail.com> (raw)
In-Reply-To: <76c5b8581002021502i2bb34967y9a88d8b25ce7fa42@mail.gmail.com>
On Tue, Feb 2, 2010 at 6:02 PM, Eugene Sajine <euguess@gmail.com> wrote:
> On Tue, Feb 2, 2010 at 5:35 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
>>This feature would have to be
>> optional in order to not confuse existing users, and not annoy users
>> of editors (like my favourite, joe) which don't save-on-exit if the
>> file hasn't changed. But I think it might be valuable to some people
>> nevertheless. And if it became popular, perhaps it could become the
>> default in some future version of git (after giving people enough
>> notice, etc, etc).
>
> But here I totally disagree, because i don't understand what is so new
> and confusing in the workflow I'm talking about?
> Why you're not confused that you MUST save before exiting your EDITOR
> in order to be able to commit (else it will fail), but the same
> workflow suddenly becomes confusing when you doing "commit --amend" or
> especially "rebase -i" ???
I think you're missing the point of people's objections.
It's pretty clear that the current behaviour is inconsistent and
confusing to new users:
- If you make a new commit and change your mind, abort your editor:
commit is aborted.
- If you amend a commit and change your mind, abort your editor:
commit gets *replaced* and newbies don't know how to get it back.
Argh!
However, whether it's inconsistent and confusing is unfortunately not
the question. The question is what can you do to possibly improve
things while a) not making backwards-incompatible changes, b) not
making things even more inconsistent, and c) not annoying existing
long-term users who like it fine the way it is. (I use the current
behaviour and I even kind of like it now that I understand it. But I
still think it's confusing and admit there may be a better way.)
git development is kind of like working at Intel or Microsoft. If you
want to achieve world domination, you don't make new versions that are
incompatible with old ones, no matter how stupid you think the old one
was.
You can however add *new* stuff. That's why I suggested adding an
option. You could even make it a config option so you only have to
set it once (just like setting your preferred editor).
> I wish i could - but, unfortunately, I'm as far from C as from the Sun
> (star;)). I'm developing a little bit in Java, but can't do C.
There's no better time to learn :)
Have fun,
Avery
next prev parent reply other threads:[~2010-02-02 23:41 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 [this message]
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
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=32541b131002021540g7a2834c9hacf2be5962f66515@mail.gmail.com \
--to=apenwarr@gmail.com \
--cc=euguess@gmail.com \
--cc=git@vger.kernel.org \
--cc=jacob.helwig@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).