Re: [PATCH 3/3] reset: Print a warning when user uses "git reset" during a merge
- From
Marc Branchaud <marcnarc@xiplink.com>
- Date
- Mar 14, 2014, 14:33 UTC
- Message-ID
- <5323131C.7070506@xiplink.com>
- In-Reply-To
- <1394771872-25940-4-git-send-email-andrew.kw.w@gmail.com>
On 14-03-14 12:37 AM, Andrew Wong wrote:
Show 6 quoted lines
> 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.