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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
