Re: git rebase interactive: usability issue

[Theodore Tso <tytso@mit.edu>]

On Thu, Jun 26, 2008 at 03:32:08AM +0400, Dmitry Potapov wrote:
> Though the user realized his mistake after my explanation of how git
> rebase works, I still believe it is a serious usability issue, because
> the same command: "git commit --amend" produces drastically different
> results depends on whether the rebase process stopped due to conflict
> or on the "edit" mark. Moreover, the commit message of second patch is
> getting lost as result of using "git commit --amend" in the former case.

This is true whether it a conflict is getting addressed during a
git-rebase or a git-merge.  The observation I would make is that git
has stopped a rebase or a merge with a conflict that the user needs to
fix up, a "git commit --amend" is almost always the wrong thing.  So I
could imagine a safety where after git discovers a merge conflict, it
sets a flag (probably a file in the .git directory) which causes "git
commit --amend" stop withan error message "this probably wasn't what
you wanted", and telling the user to use a --force command if this is
what they wanted.  This flag would be cleared on the next "git commit"
or "git reset".

In fact, we do this already for git-merge.  Why not just do the same
thing in the middle of a merge conflict with git-rebase?

      	     	       	       		- Ted