Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pathspec fatal git stash push keep-index with globs #2037

Closed
1 task done
christianbumann opened this issue Jan 23, 2019 · 23 comments · Fixed by #2119
Closed
1 task done

Pathspec fatal git stash push keep-index with globs #2037

christianbumann opened this issue Jan 23, 2019 · 23 comments · Fixed by #2119
Assignees
Milestone

Comments

@christianbumann
Copy link

christianbumann commented Jan 23, 2019

  • I was not able to find an open or closed issue matching what I'm seeing

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

64bit

$ git --version --build-options

git version 2.19.0.rc0.windows.2
cpu: x86_64
built from commit: f9c1a9c1a4c1bf131ccf13aeac422b3820fa382f
sizeof-long: 4
sizeof-size_t: 8
The issue is still present in version 2.20.1

  • Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
$ cmd.exe /c ver

Microsoft Windows [Version 10.0.17763.195]
  • What options did you set as part of the installation? Or did you choose the
    defaults?

Defaults

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

  • Any other interesting things about your environment that might be related
    to the issue you're seeing?

Reproducible on many different machines

Details

  • Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

CMD

  • What commands did you run to trigger this issue? If you can provide a

Add a file, e.g. test.testextension

untrackedfile

git stash push --all --keep-index :(glob)**/*.testextension

no error

working

Error

notworking

@dscho
Copy link
Member

dscho commented Feb 26, 2019

Since this bug report has no easy-to-run MCVE, I'll have to ask you to try again with the latest snapshot.

@christianbumann
Copy link
Author

christianbumann commented Mar 7, 2019

@dscho I just tested the issue with Git 2.21.0 and on this version, the issue is still existing. What is missing for a MVCE ? In my example above all steps are explained to reproduce this error...

@dscho
Copy link
Member

dscho commented Mar 7, 2019

@christianbumann an MCVE usually comes in the form of a copy/paste'able list of commands, and if necessary with a URL from where to clone a tiny repository to reproduce the issue ;-)

But reading again, I found some commands interspersed with the screenshots (from which I can copy exactly no text whatsoever...). Let me try first in WSL.

@dscho
Copy link
Member

dscho commented Mar 7, 2019

Okay, I tested in WSL, and I have news: git stash push --all --keep-index ':(glob)**/*.testextension' does not work. Unless test.testextension (which BTW could be made more minimal by using e.g. test.txt, it does not have to be such a long name) lives in a subdirectory.

And in WSL (and by extension, Linux, because they are close enough for this current issue), this works: git stash push --all --keep-index ':(glob)*.testextension', i.e. when you drop the **/ part.

You probably come from the Java/Ant world, where **/ means an arbitrary number of directories. And apparently this is not the case for Git, at least not for git stash.

Please test again, dropping the **/, to see whether this fixes it for you (the "regression" was caused by git stash becoming an optional built-in, which arguably brought it in line with the way Git works on Linux).

@dscho
Copy link
Member

dscho commented Mar 7, 2019

Turns out that a simple GIT_TRACE=1 points to the actual culprit: git add is called with **/*.testextension, i.e. without the :(glob) prefix.

I think we'll need something like this:

diff --git a/builtin/stash.c b/builtin/stash.c
index 794fba6e2d..23bdda3016 100644
--- a/builtin/stash.c
+++ b/builtin/stash.c
@@ -837,7 +837,7 @@ static void add_pathspecs(struct argv_array *args,
        int i;

        for (i = 0; i < ps.nr; i++)
-               argv_array_push(args, ps.items[i].match);
+               argv_array_push(args, ps.items[i].original);
 }

 /*

@dscho dscho self-assigned this Mar 7, 2019
@dscho dscho added this to the v2.21.0(2) milestone Mar 7, 2019
@christianbumann
Copy link
Author

Dropping dropping the **/ only solves the problem if the file is in the same directory. No I am working on Windows, but the developer (which is not longer working in our company) used this glossary.

The example (command above which is no longer working for us) is only a short part of a script we are using. We created a git alias which cleans up the repo (stashing modified files - cleanup - unstash) and the pattern above is to define files which are created, but shouldn't be deleted during cleanup. Unfortunately we need some expression like **./ because the files can be in any folder inside the repo.

@dscho
Copy link
Member

dscho commented Mar 7, 2019

I actually figured it out... see gitgitgadget#159

@christianbumann
Copy link
Author

Ok thank you so much for your effort and fix!

@dscho
Copy link
Member

dscho commented Mar 7, 2019

Please let me take a moment (catching my breath between three parallel projects, where this here ticket is one of them) to thank you for reporting this. Without reports like this one, I would not even be aware of the bugs, and I cannot fix what I do not know about. Granted, I would have liked the MCVE to be a bit more minimal, and a bit more convenient for me to reproduce (i.e. in a scripted form), and I was grumpy about it and shouldn't have been. I am sorry for that!

So to give you an idea what is going to happen now:

  • I'll wait until the build finishes.
  • If the build finishes with failures, I'll address them (hopefully there won't be any, or just that bogus t5570 failure on macOS that haunts our CI builds sporadically).
  • Then I will send this off to the Git mailing list for review.
  • After that, it is a bit of a waiting time (I'll actually not be waiting, but going back to other projects), to see how the core Git reviewers can help me improve the patches.
  • Once I am sure enough that the patches will be integrated into core (or "upstream") Git, I will prepare a PR for Git for Windows, and will have at least one other reviewer have a last look.
  • Then this PR will be merged, and I will ask you to test the latest snapshot.

Hopefully all of this will be done in time for v2.21.1, which I get a feeling will be happening some time soon (if the Git maintainer's recent "What's cooking" is any indication).

dscho added a commit to dscho/git that referenced this issue Mar 7, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes git-for-windows#2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit to gitgitgadget/git that referenced this issue Mar 11, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes git-for-windows#2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
dscho added a commit to dscho/git that referenced this issue Mar 11, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes git-for-windows#2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Copy link
Member

dscho commented Mar 11, 2019

So I sent the fix to the Git mailing list via gitgitgadget#159, and it was integrated into the "proposed updates" branch; I am confident that it will be make the hop to master eventually, so I opened #2119. Once the build passes, I will merge, which will kick off the snapshot build.

@dscho
Copy link
Member

dscho commented Mar 11, 2019

Okay, I merged the PR. The snapshot build is running here. Once it is done, the snapshot I would like you to test, @christianbumann, will be available at https://wingit.blob.core.windows.net/files/index.html.

@christianbumann
Copy link
Author

@dscho A first quick test from my side was successful. I will ask tomorrow some other developers from our company to test this version too...

dscho added a commit that referenced this issue Mar 11, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue Mar 11, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue Mar 11, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Copy link
Member

dscho commented Mar 12, 2019

A first quick test from my side was successful. I will ask tomorrow some other developers from our company to test this version too...

Excellent.

Please do make sure that all your use cases are covered. Nothing is more frustrating for me than fixing somebody's bug, releasing a new version of Git for Windows with too little testing by the bug reporter, only to find out that the bug was not fully fixed. You'd be surprised how often that happens...

@christianbumann
Copy link
Author

christianbumann commented Mar 12, 2019

@dscho This is not working if more than one pattern will be passed.

Example command:

git stash push --all --keep-index :(glob)**/a.txt :(glob)**/b.txt2

If any of booth files exists (a.txt or b.txt2) this won't work

error message:

git stash push --all --keep-index :(glob)**/a.txt :(glob)**/b.txt2
Saved working directory and index state WIP on master: 48959c6a3b olkj
fatal: pathspec ':(glob,prefix:0)**/a.txt' did not match any files

@dscho
Copy link
Member

dscho commented Mar 13, 2019

Okay, I tried to reproduce that, and was not able to confirm. It works over here. This is what I did (for my own ease, I reused the worktree of the regression test I introduced):

C:\git-sdk-64\usr\src\git\wip6\t\trash directory.t3905-stash-include-untracked>echo 1 >untracked.txt

C:\git-sdk-64\usr\src\git\wip6\t\trash directory.t3905-stash-include-untracked>echo 2 >untracked.txt2

C:\git-sdk-64\usr\src\git\wip6\t\trash directory.t3905-stash-include-untracked>dir untracked*
 Volume in drive C is OSDisk
 Volume Serial Number is 02D6-2667

 Directory of C:\git-sdk-64\usr\src\git\wip6\t\trash directory.t3905-stash-include-untracked

03/13/2019  11:39 AM                 4 untracked.txt
03/13/2019  11:39 AM                 4 untracked.txt2
               2 File(s)              8 bytes
               0 Dir(s)  55,683,592,192 bytes free

C:\git-sdk-64\usr\src\git\wip6\t\trash directory.t3905-stash-include-untracked>git stash push -u :(glob)**/*.txt :(glob)**/*.txt2
Saved working directory and index state WIP on master: 14579a4 Add .gitignore

C:\git-sdk-64\usr\src\git\wip6\t\trash directory.t3905-stash-include-untracked>dir untracked*
 Volume in drive C is OSDisk
 Volume Serial Number is 02D6-2667

 Directory of C:\git-sdk-64\usr\src\git\wip6\t\trash directory.t3905-stash-include-untracked

File Not Found

For the record, this is the version I tested:

C:\git-sdk-64\usr\src\git\wip6\t\trash directory.t3905-stash-include-untracked>git version --build-options
git version 2.21.0.windows.1.80.gdc2ae9a382
cpu: x86_64
built from commit: dc2ae9a38264da2af13b0f95cc4fa5eee2ebf893
sizeof-long: 4
sizeof-size_t: 8

@christianbumann
Copy link
Author

@dscho Create only one of the file which fits the pattern

C:\Dev\A\B>echo 1 >untracked.txt

C:\Dev\A\B>echo 2 >untracked.txt2

C:\Dev\A\B>dir untracked*
 Datenträger in Laufwerk C: ist Windows
 Volumeseriennummer: 1E13-129E

 Verzeichnis von C:\Dev\A\B

14.03.2019  07:29                 4 untracked.txt
14.03.2019  07:29                 4 untracked.txt2
               2 Datei(en),              8 Bytes
               0 Verzeichnis(se), 121’764’409’344 Bytes frei

C:\Dev\A\B>git stash push -u :(glob)**/*.txt :(glob)**/*.txt2
Saved working directory and index state WIP on master: 88c946a9a Merged PR 11339: Fix typo in release notes

C:\Dev\A\B>dir untracked*
 Datenträger in Laufwerk C: ist Windows
 Volumeseriennummer: 1E13-129E

 Verzeichnis von C:\Dev\A\B

Datei nicht gefunden

C:\Dev\A\B>echo 1 >untracked.txt

C:\Dev\A\B>dir untracked*
 Datenträger in Laufwerk C: ist Windows
 Volumeseriennummer: 1E13-129E

 Verzeichnis von C:\Dev\A\B

14.03.2019  07:30                 4 untracked.txt
               1 Datei(en),              4 Bytes
               0 Verzeichnis(se), 121’762’541’568 Bytes frei

C:\Dev\A\B>git stash push -u :(glob)**/*.txt :(glob)**/*.txt2
Saved working directory and index state WIP on master: 88c946a9a Merged PR 11339: Fix typo in release notes
fatal: pathspec ':(glob,prefix:0)**/*.txt2' did not match any files

C:\Dev\A\B>

git-for-windows-ci pushed a commit that referenced this issue Mar 20, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue Mar 21, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue Apr 5, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue Apr 5, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue Apr 5, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue Apr 5, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue Apr 11, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue Apr 11, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue Apr 16, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue Apr 16, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue Apr 17, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue Apr 27, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue May 8, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue May 9, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue May 10, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit to dscho/git that referenced this issue May 13, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes git-for-windows#2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci pushed a commit that referenced this issue May 14, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue May 21, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue May 22, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue May 25, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue Jun 4, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue Jun 8, 2019
When passing a list of pathspecs to, say, `git add`, we need to be
careful to use the original form, not the parsed form of the pathspecs.

This makes a difference e.g. when calling

	git stash -- ':(glob)**/*.txt'

where the original form includes the `:(glob)` prefix while the parsed
form does not.

However, in the built-in `git stash`, we passed the parsed (i.e.
incorrect) form, and `git add` would fail with the error message:

	fatal: pathspec '**/*.txt' did not match any files

at the stage where `git stash` drops the changes from the worktree, even
if `refs/stash` has been actually updated successfully.

This fixes #2037

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants