Recovering from commit --amend in rebase --interactive

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?

On 06/01/2010 12:27 PM, Peter Krefting wrote:

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

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)

Boaz

Boaz Harrosh:

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...

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

Jan Krüger:

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

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

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

On Tue, Jun 1, 2010 at 09:57, Jan Krüger <jk@jk.gs> wrote:

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.");

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

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.

On Wed, Jun 2, 2010 at 23:37, Junio C Hamano <gitster@pobox.com> wrote:

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.

On 2010-06-01 05:27, Peter Krefting wrote:

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