What's wrong with resetting with both --mixed and paths?

[EliahKagan]

The HEAD.reset method includes this code:

GitPython/git/refs/head.py

Lines 97 to 105 in e880c33

	if index:
	mode = "--mixed"
	# Tt appears some git versions declare mixed and paths deprecated.
	# See http://github.com/Byron/GitPython/issues#issue/2.
	if paths:
	mode = None
	# END special case
	# END handle index

The issue URL is broken and seems it may not be archived. Is more known about this issue, and is there anything that can be replaced with?

[Byron]

Under the assumption that the project was moved from Byron to GitPython-Developers, I thought that #2 is the issue referred to here. However, it doesn't seem to be related at all.

Maybe one can try --mixed alongside some pathspecs on the command-line to see if it works or not with more recent Git versions?

[EliahKagan]

Although I can't be certain there isn't further relevant information in the lost issue, I think I've figured this out. It's much more straightforward than I'd feared and indeed trying it out as you suggested in #1876 (comment) led directly to the answer.

Running git reset --mixed -- path always shows a warning. For example:

> git diff --staged --stat
 git/__init__.py | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)
> git reset --mixed -- git/__init__.py
warning: --mixed with paths is deprecated; use 'git reset -- <paths>' instead.
Unstaged changes after reset:
M       git/__init__.py

The suggestion of what to do instead was added in git/git@a4941a8, but the behavior of issuing a deprecation message is older than that.

It looks like it came in at git/git@0e5a7fa when git-reset was changed from being implemented as a shell script git-reset.sh (retained as an example, then later removed in git/git@49eb8d3 along with other such examples) to a builtin implemented in a newly introduced builtin-reset.c. The first stable version of git to include these changes was 1.5.4, whose release notes mention git reset becoming a builtin but do not mention the deprecation of passing paths after --mixed. But it is not to be found in the old shell script.

As for why one shouldn't write --mixed when passing paths, it seems the idea is that a reset with paths--which must always have the same effect as when --mixed is passed--is already just its own separate kind of operation from other resets. Anyway, the approach taken in the code of simply omitting --mixed, not passing --hard or --soft either, and still passing the paths after --, seems to be robust and congruent with the expanded deprecation message.

I'll open a small PR to clarify the comment.