On 14-03-14 12:37 AM, Andrew Wong wrote:
> During a merge, "--mixed" is most likely not what the user wants. Using
> "--mixed" during a merge would leave the merged changes and new files
> mixed in with the local changes. The user would have to manually clean
> up the work tree, which is non-trivial. In future releases, we want to
> make "git reset" error out when used in the middle of a merge. For now,
> we simply print out a warning to the user.
I know this approach was suggested earlier, but given these dangers it seems
silly to give this big warning on a plain "git reset" but still go ahead and
do the things the warning talks about.
Is there any issue with changing "git reset" to error-out now but letting
"git reset --mixed" proceed? Something like (note the reworded warning
message):
$ git reset
Cowardly refusing to implicitly run 'git reset --mixed' during a merge.
This would not clean up any merged changes and would not remove any new
files that were created in the work tree. It would also make it impossible
for git to automatically clean up the work tree later, so you would have to
clean up the work tree manually.
You probably meant to run 'git merge --abort' instead.
$ git reset --mixed # Stoopid git! I know what I'm doing!
$
This would mean that the 10% of git users who like to do "git reset" in the
middle of a conflicted merge will have to teach their fingers some extra
motions. But these users are all veterans, and they can more easily type in
8 extra characters (6 with completion) than new users can recover from
accidentally misusing git-reset's power.
M.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
