Recovering from commit --amend in rebase --interactive

Recovering from commit --amend in rebase --interactive

[Peter Krefting]

Hi!

I am a frequent user of rebase --interactive, and sometimes I do change a 
commit to "edit", which presents me with an already committed change, which 
I can fix up, and do "git commit --amend" on.

However, sometimes I get conflicts during rebase. In some cases I have 
already seen that conflict, so rerere handles it for me. I am still dropped 
out of rebase to manually add the fixes, though.

The problem now is that is way too easy to just do a "git commit --amend" 
like in the case above, and thus overwriting the previous commit 
unintentionally.

Is there an easy way of working around the issue?


Last time this happened to me, I *did* notice my mistake as I entered the 
editor, since it came up with the previous commit's message. However, as the 
commit message file was in a good shape, I found no way to break out of the 
amend. I ended up using "git reflog" to find out what I overwrote, then "git 
diff $commitid > savedpatch" to remember what the change that I mistakenly 
amended was, then "git checkout $commitid" and "git apply savedpatch" and 
"git add" on the changed files. What I am wondering if there is an easier 
way of recovering?

-- 
\\// Peter - http://www.softwolves.pp.se/

Re: Recovering from commit --amend in rebase --interactive

[Boaz Harrosh]

On 06/01/2010 12:27 PM, Peter Krefting wrote:
> Hi!
> 
> I am a frequent user of rebase --interactive, and sometimes I do change a 
> commit to "edit", which presents me with an already committed change, which 
> I can fix up, and do "git commit --amend" on.
> 
> However, sometimes I get conflicts during rebase. In some cases I have 
> already seen that conflict, so rerere handles it for me. I am still dropped 
> out of rebase to manually add the fixes, though.
> 
> The problem now is that is way too easy to just do a "git commit --amend" 
> like in the case above, and thus overwriting the previous commit 
> unintentionally.
> 

The prints are clear enough.

If stop do to "edit" then it prints ... you do:
git commit --amend
git rebase --continue

If stop do to merge-conflict it prints ... you do:
git add ... (Note no commit command)
git rebase --continue

You should be getting used to it after a while, I promise you

> Is there an easy way of working around the issue?
> 
> 
> Last time this happened to me, I *did* notice my mistake as I entered the 
> editor, since it came up with the previous commit's message. However, as the 
> commit message file was in a good shape, I found no way to break out of the 
> amend. 

What?!? no, why. Just empty out the message at editor and save. It will abort
any commit and do nothing. 
(For example with kwrite, ctrl-a, delete, ctrl-s, exit)

It does not matter if the commit as entered some default text for you or
not. When editor is done if file is empty (or all comments) then it will
abort and do nothing. Do not worry. The original commit is un affected.
The message is just extracted from the original commit put to a tmp file
and enter into editor. (its just a commit -c after all)

> I ended up using "git reflog" to find out what I overwrote, then "git 
> diff $commitid > savedpatch" to remember what the change that I mistakenly 
> amended was, then "git checkout $commitid" and "git apply savedpatch" and 
> "git add" on the changed files. What I am wondering if there is an easier 
> way of recovering?
> 

Boaz

Re: Recovering from commit --amend in rebase --interactive

[Jan Krüger]

Peter Krefting <peter@softwolves.pp.se> wrote:

> Last time this happened to me, I *did* notice my mistake as I entered
> the editor, since it came up with the previous commit's message.
> However, as the commit message file was in a good shape, I found no
> way to break out of the amend.

It might be easy to miss, but it's there, right in the editor:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and *an empty message aborts the commit*.
(Emphasis added)

In general, it might be helpful to warn very loudly upon doing a commit
--amend after fixing conflicts, but an implementation would probably be
ugly and for all I know, there might be people who frequently cause
conflicts while amending; those guys would probably be quite annoyed at
such a warning.

-Jan

Re: Recovering from commit --amend in rebase --interactive

[Peter Krefting]

Boaz Harrosh:

> The prints are clear enough.

The problem is that you stop reading them after a while. I've been using 
rebase actively for a couple of years, so I don't necessary pay much 
attention to what it says anymore.

And besides, if I forget to do the edits in another xterm, the help text is 
usually gone by the time I need to continue anyway...

> What?!? no, why. Just empty out the message at editor and save. It will 
> abort any commit and do nothing.

Oh. That's useful to know next time it happens :-)


Jan Krüger:

> It might be easy to miss, but it's there, right in the editor:
>
> # Please enter the commit message for your changes. Lines starting
> # with '#' will be ignored, and *an empty message aborts the commit*.
> (Emphasis added)

Indeed. There goes thinking you know what you do after having used the 
tools for a long time... :-)

-- 
\\// Peter - http://www.softwolves.pp.se/

Re: Recovering from commit --amend in rebase --interactive

[Gabriel Filion]

On 2010-06-01 05:27, Peter Krefting wrote:
> Last time this happened to me, I *did* notice my mistake as I entered
> the editor, since it came up with the previous commit's message.
> However, as the commit message file was in a good shape, I found no way
> to break out of the amend. I ended up using "git reflog" to find out
> what I overwrote, then "git diff $commitid > savedpatch" to remember
> what the change that I mistakenly amended was, then "git checkout
> $commitid" and "git apply savedpatch" and "git add" on the changed
> files. What I am wondering if there is an easier way of recovering?
> 

when you amend or rebase commits, the "old" commits are still in your
local git repository as long as you don't "git gc" them. for this, the
reflog can help you find the previous sha1 for the old commit. you can
also use "git fsck --full" to find out which commits were orphaned. once
you have the hashes, you can bring HEAD back to them.

see [1] for some simple examples of data recovery with git.

[1]:http://progit.org/book/ch9-7.html#data_recovery

-- 
Gabriel Filion

Re: Recovering from commit --amend in rebase --interactive

[Ævar Arnfjörð Bjarmason]

On Tue, Jun 1, 2010 at 09:57, Jan Krüger <jk@jk.gs> wrote:
> Peter Krefting <peter@softwolves.pp.se> wrote:
>
>> Last time this happened to me, I *did* notice my mistake as I entered
>> the editor, since it came up with the previous commit's message.
>> However, as the commit message file was in a good shape, I found no
>> way to break out of the amend.
>
> It might be easy to miss, but it's there, right in the editor:
>
> # Please enter the commit message for your changes. Lines starting
> # with '#' will be ignored, and *an empty message aborts the commit*.
> (Emphasis added)
>
> In general, it might be helpful to warn very loudly upon doing a commit
> --amend after fixing conflicts, but an implementation would probably be
> ugly and for all I know, there might be people who frequently cause
> conflicts while amending; those guys would probably be quite annoyed at
> such a warning.

I've also introduced the error Peter describes into my history because
I wasn't careful. That required some splitting / reflog fixes later.

Perhaps the best way to solve this would be to change the content of
COMMIT_EDITMSG in cases like these so it gives you an explicit warning
about what you're about to do.

We already do this for merges, from builtin/commit.c:

		if (in_merge)
			fprintf(fp,
				"#\n"
				"# It looks like you may be committing a MERGE.\n"
				"# If this is not correct, please remove the file\n"
				"#	%s\n"
				"# and try again.\n"
				"#\n",
				git_path("MERGE_HEAD"));

		fprintf(fp,
			"\n"
			"# Please enter the commit message for your changes.");

Re: Recovering from commit --amend in rebase --interactive

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

>> In general, it might be helpful to warn very loudly upon doing a commit
>> --amend after fixing conflicts, but an implementation would probably be
>> ugly and for all I know, there might be people who frequently cause
>> conflicts while amending; those guys would probably be quite annoyed at
>> such a warning.
>
> I've also introduced the error Peter describes into my history because
> I wasn't careful. That required some splitting / reflog fixes later.
>
> Perhaps the best way to solve this would be to change the content of
> COMMIT_EDITMSG in cases like these so it gives you an explicit warning
> about what you're about to do.
>
> We already do this for merges, from builtin/commit.c:

Very good point.  "Users are told when the command gives back control, is
the best "rebase -i" could do, but by definition the users are free to
shoot themselves in the foot when given control, and "commit --amend" is
the only sensible place to give further safeguard against this issue.

Thanks.

Re: Recovering from commit --amend in rebase --interactive

[Ævar Arnfjörð Bjarmason]

On Wed, Jun 2, 2010 at 23:37, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>> In general, it might be helpful to warn very loudly upon doing a commit
>>> --amend after fixing conflicts, but an implementation would probably be
>>> ugly and for all I know, there might be people who frequently cause
>>> conflicts while amending; those guys would probably be quite annoyed at
>>> such a warning.
>>
>> I've also introduced the error Peter describes into my history because
>> I wasn't careful. That required some splitting / reflog fixes later.
>>
>> Perhaps the best way to solve this would be to change the content of
>> COMMIT_EDITMSG in cases like these so it gives you an explicit warning
>> about what you're about to do.
>>
>> We already do this for merges, from builtin/commit.c:
>
> Very good point.  "Users are told when the command gives back control, is
> the best "rebase -i" could do, but by definition the users are free to
> shoot themselves in the foot when given control, and "commit --amend" is
> the only sensible place to give further safeguard against this issue.

As it happens I shot myself in the foot with this yesterday, here's a
log of what I did:

    aoeu git (404M) $ git reset HEAD^
    Unstaged changes after reset:
    M       .gitignore
    M       Makefile
    M       config.mak.in
    M       configure.ac
    M       git.c
    M       wt-status.c
    aoeu git (404M) $ git st
     M .gitignore
     M Makefile
     M config.mak.in
     M configure.ac
     M git.c
     M wt-status.c
    ?? gettext.c
    ?? gettext.h
    ?? po/
    aoeu git (404M) $ git diff
    aoeu git (404M) $ git show

        At this point the amend message should warn me that I'm about to
        merge stuff into the previous commit:

    aoeu git (404M) $ git commit --amend
    Waiting for Emacs...
    [detached HEAD f9d39c1379537fb3afdfba244c61a7328dc394f2] Merge
branch 'maint'
     Author: Junio C Hamano <gitster@pobox.com>
    aoeu git (404M) $ git st
     M wt-status.c
    ?? gettext.c
    ?? gettext.h
    ?? po/

Actually, related to that I think this documentation section could use
some work:

    http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_splitting_commits

At the time I was:

    * Going back in my history
    * Splitting apart some hunks to an older commit from that commit
    * recommiting the altered commit, leaving its commit info alone
    * Stashing the changes I'd removed into several stashes
    * git rebase --continue and applying all the stashes to one big commit later

I.e.:

    git rebase -i master
    ...
    git reset HEAD^
    git stash save --patch "stash git-pull.sh"
    git add -u
    git commit -c e06ef88fead1510587ff32715beaccf622dec2ce
    git rebase --continue

The "Commit the now-current index with whatever commit message is
appropriate now" part of the docs assumes that you don't want to keep
your old commit info around for the new rewritten commit.


Anyway, </braindump>. This is just one example of how the rebase
process could be friendlier with some minor changes, and how the
documentation could be improved.