git reset <path> returns unwanted failure status

[Stephen Leake <stephen_leake@stephe-leake.org>]

The use case:

I'm doing a 'git stash pop'; it had conflicts. At this point, 'git status' shows:

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   Target.java
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#	both modified:      DriveByInches.java
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   CommandBasedAutonomous.java
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	AerialAssist2014/src/org/usfirst/frc1939/AerialAssist2014/Autonomous/

As part of the conflict resolution, I decide to unstage Target.java:

stephe@takver$ git reset Target.java
Unstaged changes after reset:
M	CommandBasedAutonomous.java
U	DriveByInches.java
M	Target.java
stephe@takver$ echo $?
1


The issue is the error status and the messages about other files.

If I had not specified a path to 'git reset', the error status would
make sense; those files were not reset. However, since the file I
specified was reset, there should be no error.

Similarly, if I specify no path to a git command, I expect warning
messages about files in the workspace that might need attention.
However, if I do specify a path, I expect warning messages about files
in that path only.

This can be stated more concisely if the default path is considered to be
"*" (and recursive); don't error if the operation succeeded for all
files in the path; don't warn about files not in the path.

-- 
-- Stephe