| \n | if index: | \n
| \n | mode = \"--mixed\" | \n
| \n | \n |
| \n | # Tt appears some git versions declare mixed and paths deprecated. | \n
| \n | # See http://github.com/Byron/GitPython/issues#issue/2. | \n
| \n | if paths: | \n
| \n | mode = None | \n
| \n | # END special case | \n
| \n | # END handle index | \n
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?
","upvoteCount":1,"answerCount":2,"acceptedAnswer":{"@type":"Answer","text":"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.
\nRunning git reset --mixed -- path always shows a warning. For example:
> git diff --staged --stat\n git/__init__.py | 16 ++++++++++------\n 1 file changed, 10 insertions(+), 6 deletions(-)\n> git reset --mixed -- git/__init__.py\nwarning: --mixed with paths is deprecated; use 'git reset -- <paths>' instead.\nUnstaged changes after reset:\nM git/__init__.py\nThe suggestion of what to do instead was added in git/git@a4941a8, but the behavior of issuing a deprecation message is older than that.
\nIt 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.
","upvoteCount":1,"url":"https://github.com/gitpython-developers/GitPython/discussions/1876#discussioncomment-8975656"}}}What's wrong with resetting with both --mixed and paths? #1876
-
|
The Lines 97 to 105 in e880c33 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? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
Under the assumption that the project was moved from Maybe one can try |
Beta Was this translation helpful? Give feedback.
-
|
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 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 As for why one shouldn't write I'll open a small PR to clarify the comment. |
Beta Was this translation helpful? Give feedback.
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 -- pathalways shows a warning. For example:The suggestion of what to do instead was added in git/git@a4941a8, but the behavio…