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

On Wed, Jun 2, 2010 at 23:37, Junio C Hamano [off-list ref] wrote:

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

quoted

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 [off-list ref]
    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.