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

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

[Eugene Sajine]

Hi,

It seems to me it is a bug:

When git commit --amend is executed it fires up vi so i can change the
commit message. If I have something staged, then when I'm exiting vi
using :q (without doing/writing any changes), it still commits
everything staged with old message.

I believe it should actually abort amending and return to the state
before the "git commit --amend" was issued.

Thanks,
Eugene

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

[Jacob Helwig]

On Tue, Feb 2, 2010 at 12:07, Eugene Sajine <euguess@gmail.com> wrote:
> Hi,
>
> It seems to me it is a bug:
>
> When git commit --amend is executed it fires up vi so i can change the
> commit message. If I have something staged, then when I'm exiting vi
> using :q (without doing/writing any changes), it still commits
> everything staged with old message.
>
> I believe it should actually abort amending and return to the state
> before the "git commit --amend" was issued.
>
> Thanks,
> Eugene
>

I don't think this is actually the right way to go.  A _very_ common
use case for "commit --amend" is to add things to the previous commit,
without changing the commit message at all.  Yes, you can avoid having
to fire up the editor at all in this case, but it's still a perfectly
valid thing to want to do.

If you want to abort amending, and return to the state before the "git
commit --amend", you can remove all non-comment lines (IE: write out
an "empty" commit message), or have your editor exit with a non-zero
exit code (Use ":cquit").

The comment block that comes up in your editor mentions this first
method, explicitly. "..., and an empty message aborts the commit."

-Jacob

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

[Avery Pennarun]

On Tue, Feb 2, 2010 at 3:14 PM, Jacob Helwig <jacob.helwig@gmail.com> wrote:
> On Tue, Feb 2, 2010 at 12:07, Eugene Sajine <euguess@gmail.com> wrote:
>> When git commit --amend is executed it fires up vi so i can change the
>> commit message. If I have something staged, then when I'm exiting vi
>> using :q (without doing/writing any changes), it still commits
>> everything staged with old message.
>>
>> I believe it should actually abort amending and return to the state
>> before the "git commit --amend" was issued.
>
> I don't think this is actually the right way to go.  A _very_ common
> use case for "commit --amend" is to add things to the previous commit,
> without changing the commit message at all.  Yes, you can avoid having
> to fire up the editor at all in this case, but it's still a perfectly
> valid thing to want to do.

I agree and I do this all the time. However, I've also done it
accidentally before I learned the "remove the commit message and save"
trick.

Perhaps what's really missing is more documentation of how to
"unamend" if you change your mind :)  I happen to know about "git
reset HEAD@{1}" but it's not terribly obvious.

Avery

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

[Eugene Sajine]

On Tue, Feb 2, 2010 at 3:27 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> On Tue, Feb 2, 2010 at 3:14 PM, Jacob Helwig <jacob.helwig@gmail.com> wrote:
>> On Tue, Feb 2, 2010 at 12:07, Eugene Sajine <euguess@gmail.com> wrote:
>>> When git commit --amend is executed it fires up vi so i can change the
>>> commit message. If I have something staged, then when I'm exiting vi
>>> using :q (without doing/writing any changes), it still commits
>>> everything staged with old message.
>>>
>>> I believe it should actually abort amending and return to the state
>>> before the "git commit --amend" was issued.
>>
>> I don't think this is actually the right way to go.  A _very_ common
>> use case for "commit --amend" is to add things to the previous commit,
>> without changing the commit message at all.  Yes, you can avoid having
>> to fire up the editor at all in this case, but it's still a perfectly
>> valid thing to want to do.
>
> I agree and I do this all the time. However, I've also done it
> accidentally before I learned the "remove the commit message and save"
> trick.
>
> Perhaps what's really missing is more documentation of how to
> "unamend" if you change your mind :)  I happen to know about "git
> reset HEAD@{1}" but it's not terribly obvious.
>
> Avery
>

Well, i understand this logic but it seems to me that the issue is a
little bit deeper than that.
I just realized that the "rebase -i" is doing the same thing.

If you're just exiting the vi using :q without writing changes it will
perform rebase! I'm 100% sure it is not OK.

So, it seems that it will do that every time it has some
*prepopulated* message in the editor, so it doesn't understand when
changes are written and when they are not.

I believe all those actions should be treated exactly the same way as
the commit itself. If I'm writing/saving changes - it is good to go.
If not - abort.
I.e. the message can be prepopulated in the editor, but it should be
the same state as when you create a new message for commit, i.e. git
should not know anything about that message.

Thanks,
Eugene

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

[Wincent Colaiuta]

El 02/02/2010, a las 21:47, Eugene Sajine escribió:

> On Tue, Feb 2, 2010 at 3:27 PM, Avery Pennarun <apenwarr@gmail.com>  
> wrote:
>> On Tue, Feb 2, 2010 at 3:14 PM, Jacob Helwig  
>> <jacob.helwig@gmail.com> wrote:
>>> On Tue, Feb 2, 2010 at 12:07, Eugene Sajine <euguess@gmail.com>  
>>> wrote:
>>>> When git commit --amend is executed it fires up vi so i can  
>>>> change the
>>>> commit message. If I have something staged, then when I'm exiting  
>>>> vi
>>>> using :q (without doing/writing any changes), it still commits
>>>> everything staged with old message.
>>>>
>>>> I believe it should actually abort amending and return to the state
>>>> before the "git commit --amend" was issued.
>>>
>>> I don't think this is actually the right way to go.  A _very_ common
>>> use case for "commit --amend" is to add things to the previous  
>>> commit,
>>> without changing the commit message at all.  Yes, you can avoid  
>>> having
>>> to fire up the editor at all in this case, but it's still a  
>>> perfectly
>>> valid thing to want to do.
>>
>> I agree and I do this all the time. However, I've also done it
>> accidentally before I learned the "remove the commit message and  
>> save"
>> trick.
>>
>> Perhaps what's really missing is more documentation of how to
>> "unamend" if you change your mind :)  I happen to know about "git
>> reset HEAD@{1}" but it's not terribly obvious.
>>
>> Avery
>>
>
> Well, i understand this logic but it seems to me that the issue is a
> little bit deeper than that.
> I just realized that the "rebase -i" is doing the same thing.
>
> If you're just exiting the vi using :q without writing changes it will
> perform rebase! I'm 100% sure it is not OK.

As has already been pointed out, an extremely common workflow for "git  
commit --amend" is to include additional changes that were  
accidentally overlooked  in the initial commit, and no changes are  
made to the commit message.

Changing the behavior would break that perfectly reasonable, widely- 
practised workflow, and _that_ would be 100% not ok.

Lucky for you, you've already been provided with two means of aborting  
(empty commit message, and non-zero editor exit), so you might as well  
start getting used to them.

Wincent

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

[Avery Pennarun]

On Tue, Feb 2, 2010 at 3:47 PM, Eugene Sajine <euguess@gmail.com> wrote:
> If you're just exiting the vi using :q without writing changes it will
> perform rebase! I'm 100% sure it is not OK.
>
> So, it seems that it will do that every time it has some
> *prepopulated* message in the editor, so it doesn't understand when
> changes are written and when they are not.
>
> I believe all those actions should be treated exactly the same way as
> the commit itself. If I'm writing/saving changes - it is good to go.
> If not - abort.

It might be sort of neat to check the mtime of the commit message file
before and after launching the editor; then if you want, you could
force-save the file even without any changes, and git would know that
you want it changed.

Not sure I would like that behaviour better than the current way,
actually, but it's an idea.

Avery

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

[Eugene Sajine]

>
> As has already been pointed out, an extremely common workflow for "git
> commit --amend" is to include additional changes that were accidentally
> overlooked  in the initial commit, and no changes are made to the commit
> message.
>
> Changing the behavior would break that perfectly reasonable,
> widely-practised workflow, and _that_ would be 100% not ok.

I'm not against that workflow - I'm not forcing anybody to change the
commit message. The thing I'm talking about is roughly that it should
NOT treat the result of command ":q" the same way as the command
":wq".

For example IF there is a variable somewhere where message is stored:
For new commit message it is NULL and when commit is ready it is set
up to "message". We check If it is not empty and not NULL (:wq
executed),  then we can commit.
For "prepopulated" messages this variable can be is set to "message"
from the beginning, so it doesn't matter if you're writing changes or
not the check will always be true, so we can commit.
If the implementation would be like this, then I would propose to
clean up this variable after the prepopulated message is populated, so
it won't use it blindly, but only after you're overwriting the message
(even if the message is not changed).

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

[Erik Faye-Lund]

On Tue, Feb 2, 2010 at 10:56 PM, Eugene Sajine <euguess@gmail.com> wrote:
>>
>> As has already been pointed out, an extremely common workflow for "git
>> commit --amend" is to include additional changes that were accidentally
>> overlooked  in the initial commit, and no changes are made to the commit
>> message.
>>
>> Changing the behavior would break that perfectly reasonable,
>> widely-practised workflow, and _that_ would be 100% not ok.
>
> I'm not against that workflow - I'm not forcing anybody to change the
> commit message. The thing I'm talking about is roughly that it should
> NOT treat the result of command ":q" the same way as the command
> ":wq".
>

Quite a lot of text-editors on prevents a user from saving when the
buffer is unchanged, so I don't think this would actually work. Keep
in mind that vi is not the only editor one can use to edit commit
messages.

-- 
Erik "kusma" Faye-Lund

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

[Wincent Colaiuta]

El 02/02/2010, a las 22:56, Eugene Sajine escribió:

>>
>> As has already been pointed out, an extremely common workflow for  
>> "git
>> commit --amend" is to include additional changes that were  
>> accidentally
>> overlooked  in the initial commit, and no changes are made to the  
>> commit
>> message.
>>
>> Changing the behavior would break that perfectly reasonable,
>> widely-practised workflow, and _that_ would be 100% not ok.
>
> I'm not against that workflow - I'm not forcing anybody to change the
> commit message. The thing I'm talking about is roughly that it should
> NOT treat the result of command ":q" the same way as the command
> ":wq".

Why should Git care about how you exited from your EDITOR? All it  
should care about is the contents of the commit message, and the exit  
code of the editor.

> For example IF there is a variable somewhere where message is stored:
> For new commit message it is NULL and when commit is ready it is set
> up to "message". We check If it is not empty and not NULL (:wq
> executed),  then we can commit.
> For "prepopulated" messages this variable can be is set to "message"
> from the beginning, so it doesn't matter if you're writing changes or
> not the check will always be true, so we can commit.

I don't understand what change you're asking for, as things already  
work as you've just described (the "variable" is the file, .git/ 
COMMIT_EDITMSG).

> If the implementation would be like this, then I would propose to
> clean up this variable after the prepopulated message is populated, so
> it won't use it blindly, but only after you're overwriting the message
> (even if the message is not changed).

Here is where you've lost me. Not sure what you mean here, nor how  
you're going to maintain the existing behavior for all of the people  
who have grown used to it over a long, long period of time.

Wincent

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

[Eugene Sajine]

>
> Why should Git care about how you exited from your EDITOR? All it should
> care about is the contents of the commit message, and the exit code of the
> editor.

It doesn't matter which editor is used. The only thing that matters is
that you saving or not saving on exit from editor. If not saving -
abort the action.

>
>> For example IF there is a variable somewhere where message is stored:
>> For new commit message it is NULL and when commit is ready it is set
>> up to "message". We check If it is not empty and not NULL (:wq
>> executed),  then we can commit.
>> For "prepopulated" messages this variable can be is set to "message"
>> from the beginning, so it doesn't matter if you're writing changes or
>> not the check will always be true, so we can commit.
>
> I don't understand what change you're asking for, as things already work as
> you've just described (the "variable" is the file, .git/COMMIT_EDITMSG).

So, i was right in my assumption about how it is implemented - good;)

>
>> If the implementation would be like this, then I would propose to
>> clean up this variable after the prepopulated message is populated, so
>> it won't use it blindly, but only after you're overwriting the message
>> (even if the message is not changed).
>
> Here is where you've lost me. Not sure what you mean here, nor how you're
> going to maintain the existing behavior for all of the people who have grown
> used to it over a long, long period of time.

Let me explain it like this (sorry for syntax):

new commit:

COMMIT_EDITMSG = NULL;
$ git commit

in background:
$EDITOR .git/COMMIT_EDITMSG

If saved/written
COMMIT_EDITMSG=message

if (COMMIT_EDITMSG != NULL &&  !COMMIT_EDITMSG.equalsIgnoreCase("")  )  {
commit();
} else abort();

====================
amend or rebase:
COMMIT_EDITMSG = "message from commit or rebase sequence";
$ git commit --amend

in background:
$EDITOR .git/COMMIT_EDITMSG

COMMIT_EDITMSG = NULL    <======== this i think is missing. We have to
clean it after it is populated in the editor.

If written back by save:
COMMIT_EDITMSG="message from commit or rebase sequence" (it was not
changed, but saved/written)

If not saved, the check below will abort the action

if (COMMIT_EDITMSG != NULL &&  !COMMIT_EDITMSG.equalsIgnoreCase("")  )  {
commit();
} else abort();


Is that a better explanation?

So, the only change from user perspective will be that you will have
always save/write your changes/rebase sequences (even if you don't
change the message) for the program to proceed with commit
amend/rebase or whatever the same way as for the simple commit.

Thanks,
Eugene

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

[Avery Pennarun]

> amend or rebase:
> COMMIT_EDITMSG = "message from commit or rebase sequence";
> $ git commit --amend
>
> in background:
> $EDITOR .git/COMMIT_EDITMSG
>
> COMMIT_EDITMSG = NULL    <======== this i think is missing. We have to
> clean it after it is populated in the editor.

That's not going to work.  Most editors will get quite angry at you if
you modify the file while the editor has it open.  Furthermore, how do
you know how long to wait after launching the editor but before
deleting the file?

Like I suggested earlier, monitoring the mtime of the file to see if
it has changed after the editor exits, even if the file itself is
identical to what it was, might work.  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).

So you might want to submit a patch to implement an option like that.

Avery

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

[Johannes Schindelin]

Hi,

On Tue, 2 Feb 2010, Eugene Sajine wrote:

[somebody wrote this, I suspect it was Wincent]
>
> > Why should Git care about how you exited from your EDITOR? All it 
> > should care about is the contents of the commit message, and the exit 
> > code of the editor.
> 
> It doesn't matter which editor is used. The only thing that matters is 
> that you saving or not saving on exit from editor. If not saving - abort 
> the action.

No. If not saving, then it means that the user was fine with the message 
as-is.

Remember, --amend is usually for amending the _content_ of the patch, not 
so much the message.

Of course, you could come up with wonderfully complicated strategies such 
as "if nothing was added, then an unmodified commit message means 'abort', 
else it means 'go ahead'", but I hope that you agree that this would be 
very bad from the users' POV: it would be utterly confusing.

Ciao,
Dscho

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

[Eugene Sajine]

On Tue, Feb 2, 2010 at 5:35 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
>> amend or rebase:
>> COMMIT_EDITMSG = "message from commit or rebase sequence";
>> $ git commit --amend
>>
>> in background:
>> $EDITOR .git/COMMIT_EDITMSG
>>
>> COMMIT_EDITMSG = NULL    <======== this i think is missing. We have to
>> clean it after it is populated in the editor.
>
> That's not going to work.  Most editors will get quite angry at you if
> you modify the file while the editor has it open.  Furthermore, how do
> you know how long to wait after launching the editor but before
> deleting the file?

I'm not insisting on this approach by any mean - i was trying to
explain what is the problem i consider to be a bug.


>
> Like I suggested earlier, monitoring the mtime of the file to see if
> it has changed after the editor exits, even if the file itself is
> identical to what it was, might work.

Anything that would work;)

>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" ???

Frankly, I think that "rebase -i" is the best example when exiting
without save should abort, not proceed.


>
> So you might want to submit a patch to implement an option like that.
>
> Avery
>

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.

Thanks,
Eugene

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

[Johannes Schindelin]

Hi,

On Tue, 2 Feb 2010, Eugene Sajine wrote:

> Frankly, I think that "rebase -i" is the best example when exiting 
> without save should abort, not proceed.

That would be horrible! If the list of commits I want to apply happens to 
be exactly what I want without needing any reordering/removing, then it 
would abort, according to you.

Ciao,
Dscho

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

[Eugene Sajine]

>> Frankly, I think that "rebase -i" is the best example when exiting
>> without save should abort, not proceed.
>
> That would be horrible! If the list of commits I want to apply happens to
> be exactly what I want without needing any reordering/removing, then it
> would abort, according to you.
>

No! It wouldn't if you save instead of simply exiting, if you type :wq
instead :q

I'm obviously failing to express my self ...;)

NOTHING is supposed to change for you except that you have to save on
exit, write the file, confirm changes or absence of such, agree with
generated content of rebase sequence. That is all i'm talking about.

You MUST save the file when you do commit - right? Because this file
COMMIT_EDITMSG is empty. It will fail to commit otherwise - right?
The problem is that this file is NOT empty when there is a
prepopulated message like rebase -i sequence of commits or message
from commit being amended.
Therefore, you can exit without saving and the action will still
happen - which is wrong and not consistent with "commit"!

Exit without saving for me means FORGET what i was doing here . So, it
is obvious, that when I'm doing rebase -i and working with the list of
commits exit without saving should mean - FORGET about rebase.

Thanks,
Eugene

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

[Eugene Sajine]

> Of course, you could come up with wonderfully complicated strategies such
> as "if nothing was added, then an unmodified commit message means 'abort',
> else it means 'go ahead'", but I hope that you agree that this would be
> very bad from the users' POV: it would be utterly confusing.

No complicated strategies necessary.
I'm not talking about modified or not modified commit message. I'm not
forcing anybody to modify commit message in order to proceed with
commit --amend.
I'm talking about consistent behaviour of main operations:

Commit - you must save on exit from your editor, simply exiting will abort.

Same should be applied to rebase -i and of course to commit --amend as
it is still commit operation.

Even if the text is OK or you agree with generated sequence of rebase
- confirm that explicitly by saving on exit from the editor, else it
should abort. Pretty obvious to me...;)


Thanks,
'Eugene

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

[Erik Faye-Lund]

On Wed, Feb 3, 2010 at 12:34 AM, Eugene Sajine <euguess@gmail.com> wrote:
>> Of course, you could come up with wonderfully complicated strategies such
>> as "if nothing was added, then an unmodified commit message means 'abort',
>> else it means 'go ahead'", but I hope that you agree that this would be
>> very bad from the users' POV: it would be utterly confusing.
>
> No complicated strategies necessary.
> I'm not talking about modified or not modified commit message. I'm not
> forcing anybody to modify commit message in order to proceed with
> commit --amend.
> I'm talking about consistent behaviour of main operations:
>
> Commit - you must save on exit from your editor, simply exiting will abort.
>

This is where you're wrong. The reason why commit (without --amend) is
aborting when you don't save is that the default commit message is
empty, not that it wasn't saved. In fact, just saving still makes in
abort. You need to add something to the commit message and then save
to get it to perform the commit.

> Same should be applied to rebase -i and of course to commit --amend as
> it is still commit operation.
>

"rebase -i" and "commit --amend" already has the exact same logic as
commit without ammend in this regard - they abort if the buffer is
empty.

-- 
Erik "kusma" Faye-Lund

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

[Avery Pennarun]

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

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

[Junio C Hamano]

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

> No. If not saving, then it means that the user was fine with the message 
> as-is.
>
> Remember, --amend is usually for amending the _content_ of the patch, not 
> so much the message.

I very often use --amend to update only the message, so I would strongly
disagree with the "usually".

But that doesn't change my conclusion ;-) It is immaterial if you amended
the tree or the message.  If either or both changed, we do need to create
a new commit---there is no question about it, so which one is more often
done does not matter.  Eugene does not gain anything by "Remember"ing it.

What is more important is what to do when neither changed.

If you run "rebase -i" and leave the earlier "pick"s intact, it seems to
try keeping the commits intact, instead of rewriting.

It is understandable if somebody wanted to keep using the old commit
object when the committer timestamp is the _only_ thing that is different
between the original and the amended commit, after "git commit --amend" is
run.  Essentially, the behaviour of "rebase -i" for earlier "pick"s comes
from the same motivation.

Right now, if you run this in a loop:

    while hell has not frozen over
    do
	git reset && EDITOR=: git commit --amend
    done

it will keep generating almost identical commits, except for their
committer timestamps.  The very first one may have different committer
identity from the original if you are amending somebody else's commit, but
after that it will be all you over and over again, only at different
times.

I am inclined to say that it is a feature that it updates the commit in
such a case to record the _last time_ you touched the commit.  You ran
"commit --amend" and did not use the any published method to _abort_ the
amend.

As mentioned already, @{1} is your friend.  Regardless of the difference
between @{0} and @{1}, it is a way to go back to the previous commit if
you do not like the latest commit for whatever reason; the latest commit
may have a "wrong tree", a "wrong message", or a "wrong committer
timestamp".

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

[Eugene Sajine]

>
> This is where you're wrong. The reason why commit (without --amend) is
> aborting when you don't save is that the default commit message is
> empty, not that it wasn't saved. In fact, just saving still makes in
> abort. You need to add something to the commit message and then save
> to get it to perform the commit.
>
>> Same should be applied to rebase -i and of course to commit --amend as
>> it is still commit operation.
>>
>
> "rebase -i" and "commit --amend" already has the exact same logic as
> commit without ammend in this regard - they abort if the buffer is
> empty.
>
> --
> Erik "kusma" Faye-Lund
>

Thank you, but I'm not wrong, as i described the exact same thing
somewhere in my second or third message, without even knowing the
implementation details. I understand the reason WHY it is like it is,
i just don't like it as it is inconsistent and IMHO incorrect.

Thanks,
Eugene

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

[Johannes Schindelin]

Hi,

On Tue, 2 Feb 2010, Eugene Sajine wrote:

> > Of course, you could come up with wonderfully complicated strategies 
> > such as "if nothing was added, then an unmodified commit message means 
> > 'abort', else it means 'go ahead'", but I hope that you agree that 
> > this would be very bad from the users' POV: it would be utterly 
> > confusing.
> 
> No complicated strategies necessary.

Sorry, your "if message was not saved, abort" is so out of line with any 
program I use that this would be highly confusing (maybe "complicated" was 
the wrong choice of words).

IMO it would not buy us anything over the current solution, which also 
requires the user to read the manual.

Ciao,
Dscho

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

[Eugene Sajine]

> Sorry, your "if message was not saved, abort" is so out of line with any
> program I use that this would be highly confusing (maybe "complicated" was
> the wrong choice of words).

Frankly, i think it is in line with "git commit" and that's the only
thing that matters here as I have no idea what programs you're talking
about. If your programs are working without making sure that user
confirmed whatever he actually supposed to confirm, then you probably
should revisit them;)

Thanks,
Eugene

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

[Erik Faye-Lund]

On Wed, Feb 3, 2010 at 12:48 AM, Eugene Sajine <euguess@gmail.com> wrote:
>>
>> This is where you're wrong. The reason why commit (without --amend) is
>> aborting when you don't save is that the default commit message is
>> empty, not that it wasn't saved. In fact, just saving still makes in
>> abort. You need to add something to the commit message and then save
>> to get it to perform the commit.
>>
>>> Same should be applied to rebase -i and of course to commit --amend as
>>> it is still commit operation.
>>>
>>
>> "rebase -i" and "commit --amend" already has the exact same logic as
>> commit without ammend in this regard - they abort if the buffer is
>> empty.
>>
>> --
>> Erik "kusma" Faye-Lund
>>
>
> Thank you, but I'm not wrong, as i described the exact same thing
> somewhere in my second or third message, without even knowing the
> implementation details. I understand the reason WHY it is like it is,
> i just don't like it as it is inconsistent and IMHO incorrect.
>

But you are. The interface isn't inconsistent. Your model of how it
works however, is wrong.

-- 
Erik "kusma" Faye-Lund

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

[Eugene Sajine]

On Tue, Feb 2, 2010 at 7:16 PM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> On Wed, Feb 3, 2010 at 12:48 AM, Eugene Sajine <euguess@gmail.com> wrote:
>>>
>>> This is where you're wrong. The reason why commit (without --amend) is
>>> aborting when you don't save is that the default commit message is
>>> empty, not that it wasn't saved. In fact, just saving still makes in
>>> abort. You need to add something to the commit message and then save
>>> to get it to perform the commit.
>>>
>>>> Same should be applied to rebase -i and of course to commit --amend as
>>>> it is still commit operation.
>>>>
>>>
>>> "rebase -i" and "commit --amend" already has the exact same logic as
>>> commit without ammend in this regard - they abort if the buffer is
>>> empty.
>>>
>>> --
>>> Erik "kusma" Faye-Lund
>>>
>>
>> Thank you, but I'm not wrong, as i described the exact same thing
>> somewhere in my second or third message, without even knowing the
>> implementation details. I understand the reason WHY it is like it is,
>> i just don't like it as it is inconsistent and IMHO incorrect.
>>
>
> But you are. The interface isn't inconsistent. Your model of how it
> works however, is wrong.
>
> --
> Erik "kusma" Faye-Lund
>

I'm sorry, but I don't get in which part my model is so wrong? The only
difference i see between your and my explanation is that you mentioned the
fact that simply saving the pregenerated new commit message is not working
because there is no meaningful (uncommented) string inserted into the
template. But this
doesn't change the problem it self, so I don't think it is relevant.

What is relevant though is that in current workflow with "rebase -i"
you have to remove! all
commits listed for rebase and save! the file in order to cancel! rebase
operation. This is very strange user interaction model IMHO

Instead of being explicit in applying the changes, we are explicit in
cancelling the operation. Very strange...

Thanks,
Eugene

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

[SZEDER Gábor]

On Tue, Feb 02, 2010 at 07:55:31PM -0500, Eugene Sajine wrote:
> On Tue, Feb 2, 2010 at 7:16 PM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> > On Wed, Feb 3, 2010 at 12:48 AM, Eugene Sajine <euguess@gmail.com> wrote:
> >>>
> >>> This is where you're wrong. The reason why commit (without --amend) is
> >>> aborting when you don't save is that the default commit message is
> >>> empty, not that it wasn't saved. In fact, just saving still makes in
> >>> abort. You need to add something to the commit message and then save
> >>> to get it to perform the commit.
> >>>
> >>>> Same should be applied to rebase -i and of course to commit --amend as
> >>>> it is still commit operation.
> >>>>
> >>>
> >>> "rebase -i" and "commit --amend" already has the exact same logic as
> >>> commit without ammend in this regard - they abort if the buffer is
> >>> empty.
> >>>
> >>> --
> >>> Erik "kusma" Faye-Lund
> >>>
> >>
> >> Thank you, but I'm not wrong, as i described the exact same thing
> >> somewhere in my second or third message, without even knowing the
> >> implementation details. I understand the reason WHY it is like it is,
> >> i just don't like it as it is inconsistent and IMHO incorrect.
> >>
> >
> > But you are. The interface isn't inconsistent. Your model of how it
> > works however, is wrong.
> >
> > --
> > Erik "kusma" Faye-Lund
> >
> 
> I'm sorry, but I don't get in which part my model is so wrong? The only
> difference i see between your and my explanation is that you mentioned the
> fact that simply saving the pregenerated new commit message is not working
> because there is no meaningful (uncommented) string inserted into the
> template. But this
> doesn't change the problem it self, so I don't think it is relevant.
> 
> What is relevant though is that in current workflow with "rebase -i"
> you have to remove! all
> commits listed for rebase and save! the file in order to cancel! rebase
> operation. This is very strange user interaction model IMHO
> 
> Instead of being explicit in applying the changes, we are explicit in
> cancelling the operation. Very strange...

No.  In case of rebase -i, exiting the editor is being explicit in
"the todo file now contains what you should do, so do it".  And if the
todo file happens to be empty, then there is nothing to do, so do
nothing.  The same applies to commit and commit --amend: exiting the
editor is being explicit in "the COMMIT_MSG file now contains what you
should put in the commit message".  But not having a commit message is
a really bad idea, therefore git complains and doesn't do that (unless
overridden by some command line option).


Best,
Gábor

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

[Larry D'Anna]

* Avery Pennarun (apenwarr@gmail.com) [100202 18:41]:
> 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).

Or, he can set his $EDITOR to a script that checks the mtime.

    --larry

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

[Matthieu Moy]

Eugene Sajine <euguess@gmail.com> writes:

> Thank you, but I'm not wrong, as i described the exact same thing
> somewhere in my second or third message, without even knowing the
> implementation details. I understand the reason WHY it is like it is,
> i just don't like it as it is inconsistent and IMHO incorrect.

Just try:

Create a file.
1) Launch emacs, save and quit.
2) Launch emacs, don't save, and quit.

>From outside, it's EXACTLY the same thing. In the first case, emacs
will just tell you "no change need to be saved" and quit, in the
second, it'll quit. Try deleting the file in the meantime, it won't
change the behavior.

Now, what would you do about this? Ignore Emacs and force people to
use vi?

People have been spending a whole thread to explain you that it's not
going to work. I think it'll either be time to acknowledge that, or to
learn C and write a patch. Or perhaps try to write it in Java to
understand why it doesn't work.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Matthieu Moy]

SZEDER Gábor <szeder@ira.uka.de> writes:

> No.  In case of rebase -i, exiting the editor is being explicit in
> "the todo file now contains what you should do, so do it".  And if the
> todo file happens to be empty, then there is nothing to do, so do
> nothing.

It's not true. The todolist is the list of things to do after you
rewind your branch to the destination branch. Strictly speaking, an
empty todolist should mean to drop all the patches (like a todolist
with just one line would mean to drop all the others). But a user
never wants to do that (otherwise, "git reset" would be the right
command), so "git rebase -i" considers it as a special case.

My 2 cents,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Johannes Schindelin]

Hi,

On Tue, 2 Feb 2010, Eugene Sajine wrote:

> > Sorry, your "if message was not saved, abort" is so out of line with 
> > any program I use that this would be highly confusing (maybe 
> > "complicated" was the wrong choice of words).
> 
> Frankly, i think it is in line with "git commit" and that's the only 
> thing that matters here as I have no idea what programs you're talking 
> about.

It's not. 'git commit' will abort if you delete all _and save_. So it is 
not the saving part, it is the deleting all part. And that's exactly how 
rebase -i works, or add -e: if you delete all and save, it aborts.

Ciao,
Dscho

aborting rebase -i right at the start, was Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written

[Johannes Schindelin]

Hi,

On Wed, 3 Feb 2010, Matthieu Moy wrote:

> Strictly speaking, an empty [rebase -i] todolist should mean to drop all 
> the patches (like a todolist with just one line would mean to drop all 
> the others). But a user never wants to do that (otherwise, "git reset" 
> would be the right command), so "git rebase -i" considers it as a 
> special case.

Actually, it is a design bug, but it was the only sane way I could think 
of aborting the rebase.

Note that there _are_ users who want to do that ("let me see what commits 
I have, ah, oh, okay, I want none of them"). I am one of those. That's 
where the underadvertised "noop" command comes in.

Ciao,
Dscho

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

[Jeff King]

On Wed, Feb 03, 2010 at 01:15:35AM -0500, Larry D'Anna wrote:

> * Avery Pennarun (apenwarr@gmail.com) [100202 18:41]:
> > 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).
> 
> Or, he can set his $EDITOR to a script that checks the mtime.

Agreed. It could even look like this:

-- >8 --
$ cat >vi-must-edit <<'EOF'
#!/usr/bin/perl
sub mtime { (stat $_[0])[9] }
my $old = mtime($ARGV[-1]);
system('vi', @ARGV) and die "vi failed";
if (mtime($ARGV[-1]) == $old) {
  print STDERR "Aborting unmodified message\n";
  exit 1;
}
exit 0
EOF
$ chmod +x vi-must-edit
$ GIT_EDITOR=$PWD/vi-must-edit; export GIT_EDITOR
$ git commit --amend ;# and then quit the editor immediately
Aborting unmodified message
error: There was a problem with the editor 'vi-must-edit'.
Please supply the message using either -m or -F option.

-- 8< --

Do note, though, that there is a subtle race condition in using the
mtime. If you make a change and save within a second of the editor
starting, it will be ignored. To be thorough, you would probably want to
check the size and inode, as well.

-Peff

Re: aborting rebase -i right at the start, was Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written

[SZEDER Gábor]

On Wed, Feb 03, 2010 at 10:08:50AM +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Wed, 3 Feb 2010, Matthieu Moy wrote:
> 
> > Strictly speaking, an empty [rebase -i] todolist should mean to drop all 
> > the patches (like a todolist with just one line would mean to drop all 
> > the others). But a user never wants to do that (otherwise, "git reset" 
> > would be the right command), so "git rebase -i" considers it as a 
> > special case.
> 
> Actually, it is a design bug, but it was the only sane way I could think 
> of aborting the rebase.
> 
> Note that there _are_ users who want to do that ("let me see what commits 
> I have, ah, oh, okay, I want none of them"). I am one of those.

I regularly mess up the todo file so badly that I don't want to bother
with undo but rather start over from the beginning.


Best,
Gábor

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

[Paolo Bonzini]

On 02/03/2010 01:09 AM, Eugene Sajine wrote:
>> Sorry, your "if message was not saved, abort" is so out of line with any
>> program I use that this would be highly confusing (maybe "complicated" was
>> the wrong choice of words).
>
> Frankly, i think it is in line with "git commit"

The fundamental problem is this.  The behavior of "git commit" can be 
explained in two ways: a) abort if not saved; b) abort if empty.  (a) 
may be an easier guess from experience (you type ":q!" at the vi 
prompt), but (b) is clear from the error message ("commit has empty 
message--aborting").  All this is irrefutable.

Now, the scientific method to see which one is correct, would be to try 
other commands including "git commit --amend" and see which of the two 
hypotheses was right.  It turns out to be that (b) is correct and 
consistent across various commands; instead you insist that everything 
else should be modified to conform to (a).  Since git is already 
consistent, and since nobody can think of a way to implement your 
proposal, there is obvious resistence to any change in this area.

Paolo

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

[Jeff King]

On Wed, Feb 03, 2010 at 04:31:50AM -0500, Jeff King wrote:

> > Or, he can set his $EDITOR to a script that checks the mtime.
> 
> Agreed. It could even look like this:

Also, while we are talking about editor-specific hacks, if you are using
vim you can use ":cq" to exit with an error code.

-Peff

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

[Eugene Sajine]

On Wed, Feb 3, 2010 at 2:31 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Eugene Sajine <euguess@gmail.com> writes:
>
>> Thank you, but I'm not wrong, as i described the exact same thing
>> somewhere in my second or third message, without even knowing the
>> implementation details. I understand the reason WHY it is like it is,
>> i just don't like it as it is inconsistent and IMHO incorrect.
>
> Just try:
>
> Create a file.
> 1) Launch emacs, save and quit.
> 2) Launch emacs, don't save, and quit.
>
> From outside, it's EXACTLY the same thing. In the first case, emacs
> will just tell you "no change need to be saved" and quit, in the
> second, it'll quit. Try deleting the file in the meantime, it won't
> change the behavior.
>
> Now, what would you do about this? Ignore Emacs and force people to
> use vi?
>
> People have been spending a whole thread to explain you that it's not
> going to work. I think it'll either be time to acknowledge that, or to
> learn C and write a patch. Or perhaps try to write it in Java to
> understand why it doesn't work.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>

Tell me you're not serious, please;) I'm working with computers for
more than 20 years and I do understand how editors are opening files.
If you are serious though...:

Please, do not assume i don't understand that file opened in editor
and saved with no changes will be the same as not saved.

Please, do not assume i don't understand that current implementation
does not allow to correctly abort by simply quiting the editor,
because it uses the file content only to verify if it can proceed.


I will stop trying to explain the problem here, but the solution, that
i think should work:

The solution should be as Avery proposed - to monitor file
modification timestamp as well as the content.
Timestamp should be remembered by git when editor is fired up and then
checked when you're exiting the editor. If it is the same - it means
that user canceled the whole operation by not confirming the file
content by save. If the timestamp is bigger than the saved one and the
message is not empty - we can proceed. Something like that.

And finally:

I DO highly appreciate everybody's time spent on every discussion and
particularly this one. I ask you to excuse me if i was failing to
properly express my thoughts or if i was too emotional at times.

Thanks a lot,
Eugene

Re: aborting rebase -i right at the start, was Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written

[Eugene Sajine]

2010/2/3 SZEDER Gábor <szeder@ira.uka.de>:
> On Wed, Feb 03, 2010 at 10:08:50AM +0100, Johannes Schindelin wrote:
>> Hi,
>>
>> On Wed, 3 Feb 2010, Matthieu Moy wrote:
>>
>> > Strictly speaking, an empty [rebase -i] todolist should mean to drop all
>> > the patches (like a todolist with just one line would mean to drop all
>> > the others). But a user never wants to do that (otherwise, "git reset"
>> > would be the right command), so "git rebase -i" considers it as a
>> > special case.
>>
>> Actually, it is a design bug, but it was the only sane way I could think
>> of aborting the rebase.
>>
>> Note that there _are_ users who want to do that ("let me see what commits
>> I have, ah, oh, okay, I want none of them"). I am one of those.
>
> I regularly mess up the todo file so badly that I don't want to bother
> with undo but rather start over from the beginning.
>
>
> Best,
> Gábor
>
>

I already described the solution which i think should be implemented
in old thread I will just repeat it here for easier tracking:

The solution should be as Avery proposed - to monitor file
modification timestamp as well as the content.
Timestamp should be remembered by git when editor is fired up and then
checked when you're exiting the editor. If it is the same - it means
that user canceled the whole operation by *not* confirming the file
content by save. If the timestamp is bigger than the saved one and the
message is not empty - we can proceed.

I.e. in case of rebase -i you will be able to abort the operation by
simply exiting the editor without save in any state at any moment and
start from the beginning.

Thanks,
Eugene

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

[Jonathan Nieder]

Eugene Sajine wrote:
> On Wed, Feb 3, 2010 at 2:31 AM, Matthieu Moy

>> Just try:
>>
>> Create a file.
>> 1) Launch emacs, save and quit.
>> 2) Launch emacs, don't save, and quit.
>>
>> From outside, it's EXACTLY the same thing. In the first case, emacs
>> will just tell you "no change need to be saved" and quit, in the
>> second, it'll quit. Try deleting the file in the meantime, it won't
>> change the behavior.

> Please, do not assume i don't understand that file opened in editor
> and saved with no changes will be the same as not saved.
> 
> Please, do not assume i don't understand that current implementation
> does not allow to correctly abort by simply quiting the editor,
> because it uses the file content only to verify if it can proceed.

I’ll bite.  Please reread Mattheiu’s message.  Pay particular attention
to the lines

	In the first case, emacs
	will just tell you "no change need to be saved" and quit, in the
	second, it'll quit.

and

	Try deleting the file in the meantime, it won't
	change the behavior.

and consider what this means about what is happening and the resulting
stat() information.

It is a bit frustrating to read this thread because Mattheiu was not the
first thing to say this (and many have mentioned other problems, too,
such as people’s muscle memory), but you do not seem to respond to them.
Instead, you keep repeating the same thing...

Hope that helps,
Jonathan

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

[Jonathan Nieder]

Jonathan Nieder wrote:

> It is a bit frustrating to read this thread because Mattheiu was not the
> first thing to say this

s/thing/person/

Sorry, Mattheiu. ;-)

Kind regards,
Jonathan

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

[Avery Pennarun]

On Wed, Feb 3, 2010 at 4:31 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Feb 03, 2010 at 01:15:35AM -0500, Larry D'Anna wrote:
>> * Avery Pennarun (apenwarr@gmail.com) [100202 18:41]:
>> > 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).
>>
>> Or, he can set his $EDITOR to a script that checks the mtime.

Nice.

> Do note, though, that there is a subtle race condition in using the
> mtime. If you make a change and save within a second of the editor
> starting, it will be ignored. To be thorough, you would probably want to
> check the size and inode, as well.

Or just the file contents.

Avery

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

[Wincent Colaiuta]

El 03/02/2010, a las 16:45, Eugene Sajine escribió:

> On Wed, Feb 3, 2010 at 2:31 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Eugene Sajine <euguess@gmail.com> writes:
>>
>>> Thank you, but I'm not wrong, as i described the exact same thing
>>> somewhere in my second or third message, without even knowing the
>>> implementation details. I understand the reason WHY it is like it  
>>> is,
>>> i just don't like it as it is inconsistent and IMHO incorrect.
>>
>> Just try:
>>
>> Create a file.
>> 1) Launch emacs, save and quit.
>> 2) Launch emacs, don't save, and quit.
>>
>> From outside, it's EXACTLY the same thing. In the first case, emacs
>> will just tell you "no change need to be saved" and quit, in the
>> second, it'll quit. Try deleting the file in the meantime, it won't
>> change the behavior.
>>
>> Now, what would you do about this? Ignore Emacs and force people to
>> use vi?
>>
>> People have been spending a whole thread to explain you that it's not
>> going to work. I think it'll either be time to acknowledge that, or  
>> to
>> learn C and write a patch. Or perhaps try to write it in Java to
>> understand why it doesn't work.
>>
>> --
>> Matthieu Moy
>> http://www-verimag.imag.fr/~moy/
>>
>
> Tell me you're not serious, please;) I'm working with computers for
> more than 20 years and I do understand how editors are opening files.
> If you are serious though...:
>
> Please, do not assume i don't understand that file opened in editor
> and saved with no changes will be the same as not saved.
>
> Please, do not assume i don't understand that current implementation
> does not allow to correctly abort by simply quiting the editor,
> because it uses the file content only to verify if it can proceed.
>
>
> I will stop trying to explain the problem here, but the solution, that
> i think should work:
>
> The solution should be as Avery proposed - to monitor file
> modification timestamp as well as the content.
> Timestamp should be remembered by git when editor is fired up and then
> checked when you're exiting the editor. If it is the same - it means
> that user canceled the whole operation by not confirming the file
> content by save. If the timestamp is bigger than the saved one and the
> message is not empty - we can proceed. Something like that.
>
> And finally:
>
> I DO highly appreciate everybody's time spent on every discussion and
> particularly this one. I ask you to excuse me if i was failing to
> properly express my thoughts or if i was too emotional at times.

Perhaps you could invest a little time actually reading what people  
have written. Your proposal won't work because in the case where the  
user wants to keep the commit message without any modifications many  
editors won't touch the file even if people explicitly save it.

Wincent

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

[Matthieu Moy]

Eugene Sajine <euguess@gmail.com> writes:

> Tell me you're not serious, please;) I'm working with computers for
> more than 20 years and I do understand how editors are opening files.
> If you are serious though...:

I'm damned serious. If you've been working for 20 years with
computers, you probably understand what "no change need to be saved"
mean.

> The solution should be as Avery proposed - to monitor file
> modification timestamp as well as the content.

Try it. I do mean "try it". I don't think anyone will be able to
explain you better than it has already been done, but ... it doesn't
work.

So, again, stop arguing, try it, and see by yourself. I promise public
apologies if you prove me wrong with an actually working piece of
code.

> Timestamp should be remembered by git when editor is fired up and then
> checked when you're exiting the editor.

Which doesn't work reliable, as you would have noticed by reading my
message.

(and yes, I'm tired and angry after a long day of work ;-) ).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Eugene Sajine]

On Wed, Feb 3, 2010 at 1:21 PM, Wincent Colaiuta <win@wincent.com> wrote:
> El 03/02/2010, a las 16:45, Eugene Sajine escribió:
>
>> On Wed, Feb 3, 2010 at 2:31 AM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>>
>>> Eugene Sajine <euguess@gmail.com> writes:
>>>
>>>> Thank you, but I'm not wrong, as i described the exact same thing
>>>> somewhere in my second or third message, without even knowing the
>>>> implementation details. I understand the reason WHY it is like it is,
>>>> i just don't like it as it is inconsistent and IMHO incorrect.
>>>
>>> Just try:
>>>
>>> Create a file.
>>> 1) Launch emacs, save and quit.
>>> 2) Launch emacs, don't save, and quit.
>>>
>>> From outside, it's EXACTLY the same thing. In the first case, emacs
>>> will just tell you "no change need to be saved" and quit, in the
>>> second, it'll quit. Try deleting the file in the meantime, it won't
>>> change the behavior.
>>>
>>> Now, what would you do about this? Ignore Emacs and force people to
>>> use vi?
>>>
>>> People have been spending a whole thread to explain you that it's not
>>> going to work. I think it'll either be time to acknowledge that, or to
>>> learn C and write a patch. Or perhaps try to write it in Java to
>>> understand why it doesn't work.
>>>
>>> --
>>> Matthieu Moy
>>> http://www-verimag.imag.fr/~moy/
>>>
>>
>> Tell me you're not serious, please;) I'm working with computers for
>> more than 20 years and I do understand how editors are opening files.
>> If you are serious though...:
>>
>> Please, do not assume i don't understand that file opened in editor
>> and saved with no changes will be the same as not saved.
>>
>> Please, do not assume i don't understand that current implementation
>> does not allow to correctly abort by simply quiting the editor,
>> because it uses the file content only to verify if it can proceed.
>>
>>
>> I will stop trying to explain the problem here, but the solution, that
>> i think should work:
>>
>> The solution should be as Avery proposed - to monitor file
>> modification timestamp as well as the content.
>> Timestamp should be remembered by git when editor is fired up and then
>> checked when you're exiting the editor. If it is the same - it means
>> that user canceled the whole operation by not confirming the file
>> content by save. If the timestamp is bigger than the saved one and the
>> message is not empty - we can proceed. Something like that.
>>
>> And finally:
>>
>> I DO highly appreciate everybody's time spent on every discussion and
>> particularly this one. I ask you to excuse me if i was failing to
>> properly express my thoughts or if i was too emotional at times.
>
> Perhaps you could invest a little time actually reading what people have
> written. Your proposal won't work because in the case where the user wants
> to keep the commit message without any modifications many editors won't
> touch the file even if people explicitly save it.
>
> Wincent
>
>

Thank you for clarifying that.

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.

I'm very sorry for confusion, so, please, accept my apologies for
being stubborn.

I hope it is clear that my only intention is to try to make git better
and provide useful feedback and I'm sorry i didn't succeed this time.

Thanks,
Eugene

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

[Avery Pennarun]

On Wed, Feb 3, 2010 at 1:49 PM, Eugene Sajine <euguess@gmail.com> wrote:
> 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

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

[Eugene Sajine]

> 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

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

[Avery Pennarun]

On Wed, Feb 3, 2010 at 2:27 PM, Eugene Sajine <euguess@gmail.com> wrote:
>> 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