Re: git rebase interactive: usability issue

From: Theodore Tso <tytso@mit.edu>
Date: Jun 26, 2008, 12:13 UTC
Message-ID: <20080626121303.GF8610@mit.edu>
In-Reply-To: <20080625233208.GE5737@dpotapov.dyndns.org>

On Thu, Jun 26, 2008 at 03:32:08AM +0400, Dmitry Potapov wrote:

Show 6 quoted lines

> 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