Failed stash caused untracked changes to be lost

Failed stash caused untracked changes to be lost

[Quinn, David]

Issue: While running a git stash command including the '-u' flag to include untracked files, the command failed due to arguments in the incorrect order. After this untracked files the were present had been removed and permanently lost.

Environment: Windows 10, Powershell w/ PoshGit


State before running command: 9 Modified files, 2 (new) untracked files

Note: I only wanted to commit some of the modified files (essentially all the files/changes I wanted to commit were in one directory)

Actual command run:  git stash push -u -- Directory/To/Files/* -m "My Message"

Returned:

    Saved working directory and index state WIP on [BranchName]: [Commit hash] [Commit Message]
    fatal: pathspec '-m' did not match any files
    error: unrecognized input

State after Command ran: 9 Modifed files, 0 untracked files


The command I should have ran should have been

    git stash push -u -m "My Message"? -- Directory/To/Files/*


I have found the stash that was created by running this command:

    gitk --all $(git fsck --no-reflog | Select-String "(dangling commit )(.*)" | %{ $_.Line.Split(' ')[2] })
?
and searching for the commit number that was returned from the original (paritally failed??) stash command. However there is nothing in that stash. It is empty.



I think that the fact my untracked files were lost is not correct behaviour and hence why I'm filing this bug report




________________________________
NOTICE: This message, and any attachments, are for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at E-Communication Disclaimer<http://www.cmegroup.com/tools-information/communications/e-communication-disclaimer.html>. If you are not the intended recipient, please delete this message. CME Group and its subsidiaries reserve the right to monitor all email communications that occur on CME Group information systems.

Re: Failed stash caused untracked changes to be lost

[Thomas Gummerer]

On 10/23, Quinn, David wrote:
> 
> Issue: While running a git stash command including the '-u' flag to include untracked files, the command failed due to arguments in the incorrect order. After this untracked files the were present had been removed and permanently lost.

Thanks for your report (and sorry for the late reply)!

I believe this (somewhat) fixed in 833622a945 ("stash push: avoid
printing errors", 2018-03-19), which was first included in Git 2.18.
Your message doesn't state which version of Git you encountered the
bug, but I'm going to assume with something below 2.18 (For future
reference, please include the version of Git in bug reports, or even
better test with the latest version of Git, as the bug may have been
fixed in the meantime).

Now I'm saying somewhat fixed above, because we still create an stash
if a pathspec that doesn't match any files is passed to the command,
but then don't remove anything from the working tree, which is a bit
confusing.

I think the right solution here would be to error out early if we were
given a pathspec that doesn't match anything.  I'll look into that,
unless you're interested in giving it a try? :)

> Environment: Windows 10, Powershell w/ PoshGit
> 
> 
> State before running command: 9 Modified files, 2 (new) untracked files
> 
> Note: I only wanted to commit some of the modified files (essentially all the files/changes I wanted to commit were in one directory)
> 
> Actual command run:  git stash push -u -- Directory/To/Files/* -m "My Message"
> 
> Returned:
> 
>     Saved working directory and index state WIP on [BranchName]: [Commit hash] [Commit Message]
>     fatal: pathspec '-m' did not match any files
>     error: unrecognized input
> 
> State after Command ran: 9 Modifed files, 0 untracked files
> 
> 
> The command I should have ran should have been
> 
>     git stash push -u -m "My Message"? -- Directory/To/Files/*
> 
> 
> I have found the stash that was created by running this command:
> 
>     gitk --all $(git fsck --no-reflog | Select-String "(dangling commit )(.*)" | %{ $_.Line.Split(' ')[2] })
> ?
> and searching for the commit number that was returned from the original (paritally failed??) stash command. However there is nothing in that stash. It is empty.
> 
> 
> 
> I think that the fact my untracked files were lost is not correct behaviour and hence why I'm filing this bug report
> 
> 
> 
> 
> ________________________________
> NOTICE: This message, and any attachments, are for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at E-Communication Disclaimer<http://www.cmegroup.com/tools-information/communications/e-communication-disclaimer.html>. If you are not the intended recipient, please delete this message. CME Group and its subsidiaries reserve the right to monitor all email communications that occur on CME Group information systems.

RE: Failed stash caused untracked changes to be lost

[Quinn, David]

Hi,

Thanks for the reply. Sorry I forgot the version number, completely slipped my mind. At the time of writing the report it was Git ~ 2.17 I believe. All of our software is updated centrally at my work, we have received an update since writing this to 2.19.1. Unfortunately because of it being centrally controlled, I couldn't update and try the latest version at the time (and now I can't go back and check exactly what version I had).

I've never even looked at the git source or contributing before so I wouldn't be sure where to start. If you (or someone) is happy to point me in the right direction I'd be happy to take a look, I can't promise I'll be able to get anything done in a timely manner (or at all)

Thanks

-----Original Message-----
From: Thomas Gummerer <t.gummerer@gmail.com> 
Sent: 03 November 2018 15:35
To: Quinn, David <David.Quinn@cmegroup.com>
Cc: git@vger.kernel.org
Subject: Re: Failed stash caused untracked changes to be lost

Exercise Caution: This email is from an external source.


On 10/23, Quinn, David wrote:
>
> Issue: While running a git stash command including the '-u' flag to include untracked files, the command failed due to arguments in the incorrect order. After this untracked files the were present had been removed and permanently lost.

Thanks for your report (and sorry for the late reply)!

I believe this (somewhat) fixed in 833622a945 ("stash push: avoid printing errors", 2018-03-19), which was first included in Git 2.18.
Your message doesn't state which version of Git you encountered the bug, but I'm going to assume with something below 2.18 (For future reference, please include the version of Git in bug reports, or even better test with the latest version of Git, as the bug may have been fixed in the meantime).

Now I'm saying somewhat fixed above, because we still create an stash if a pathspec that doesn't match any files is passed to the command, but then don't remove anything from the working tree, which is a bit confusing.

I think the right solution here would be to error out early if we were given a pathspec that doesn't match anything.  I'll look into that, unless you're interested in giving it a try? :)

> Environment: Windows 10, Powershell w/ PoshGit
>
>
> State before running command: 9 Modified files, 2 (new) untracked 
> files
>
> Note: I only wanted to commit some of the modified files (essentially 
> all the files/changes I wanted to commit were in one directory)
>
> Actual command run:  git stash push -u -- Directory/To/Files/* -m "My Message"
>
> Returned:
>
>     Saved working directory and index state WIP on [BranchName]: [Commit hash] [Commit Message]
>     fatal: pathspec '-m' did not match any files
>     error: unrecognized input
>
> State after Command ran: 9 Modifed files, 0 untracked files
>
>
> The command I should have ran should have been
>
>     git stash push -u -m "My Message"? -- Directory/To/Files/*
>
>
> I have found the stash that was created by running this command:
>
>     gitk --all $(git fsck --no-reflog | Select-String "(dangling 
> commit )(.*)" | %{ $_.Line.Split(' ')[2] }) ?
> and searching for the commit number that was returned from the original (paritally failed??) stash command. However there is nothing in that stash. It is empty.
>
>
>
> I think that the fact my untracked files were lost is not correct 
> behaviour and hence why I'm filing this bug report
>
>
>
>
> ________________________________
> NOTICE: This message, and any attachments, are for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at E-Communication Disclaimer<http://www.cmegroup.com/tools-information/communications/e-communication-disclaimer.html>. If you are not the intended recipient, please delete this message. CME Group and its subsidiaries reserve the right to monitor all email communications that occur on CME Group information systems.

Re: Failed stash caused untracked changes to be lost

[Thomas Gummerer]

On 11/05, Quinn, David wrote:
> Hi,
>
> Thanks for the reply. Sorry I forgot the version number, completely
> slipped my mind. At the time of writing the report it was Git ~ 2.17
> I believe. All of our software is updated centrally at my work, we
> have received an update since writing this to 2.19.1. Unfortunately
> because of it being centrally controlled, I couldn't update and try
> the latest version at the time (and now I can't go back and check
> exactly what version I had).
>
> I've never even looked at the git source or contributing before so I
> wouldn't be sure where to start. If you (or someone) is happy to
> point me in the right direction I'd be happy to take a look, I can't
> promise I'll be able to get anything done in a timely manner (or at
> all)

Sure I'd be happy to help :) There's a nice document in the
git-for-windows repository [*1*] that gives a good introduction into
developing git.  Some of the advise is applicable to both Windows and
linux, but it should be especially helpful for you as you seem to be
working in a windows environment.

The stash implementation is currently written in shell script, and
lives in 'git-stash.sh'.  There is currently an effort under way of
re-writing this in C, but as we don't know when that's going to be
merged yet, it's probably worth fixing this in the shell script for
now.

Don't worry about making any promises, or getting it done very soon.
This is no longer a data loss bug at this time, so it's not critical
to fix it immediately, but it should definitely be fixed at some
point.

 Some of us also hang out on the #git-devel IRC channel on freenode,
which can be a good place to ask questions.

[*1*]: https://github.com/git-for-windows/git/blob/master/CONTRIBUTING.md

> Thanks
> 
> -----Original Message-----
> From: Thomas Gummerer <t.gummerer@gmail.com> 
> Sent: 03 November 2018 15:35
> To: Quinn, David <David.Quinn@cmegroup.com>
> Cc: git@vger.kernel.org
> Subject: Re: Failed stash caused untracked changes to be lost
> 
> Exercise Caution: This email is from an external source.
> 
> 
> On 10/23, Quinn, David wrote:
> >
> > Issue: While running a git stash command including the '-u' flag to include untracked files, the command failed due to arguments in the incorrect order. After this untracked files the were present had been removed and permanently lost.
> 
> Thanks for your report (and sorry for the late reply)!
> 
> I believe this (somewhat) fixed in 833622a945 ("stash push: avoid printing errors", 2018-03-19), which was first included in Git 2.18.
> Your message doesn't state which version of Git you encountered the bug, but I'm going to assume with something below 2.18 (For future reference, please include the version of Git in bug reports, or even better test with the latest version of Git, as the bug may have been fixed in the meantime).
> 
> Now I'm saying somewhat fixed above, because we still create an stash if a pathspec that doesn't match any files is passed to the command, but then don't remove anything from the working tree, which is a bit confusing.
> 
> I think the right solution here would be to error out early if we were given a pathspec that doesn't match anything.  I'll look into that, unless you're interested in giving it a try? :)
> 
> > Environment: Windows 10, Powershell w/ PoshGit
> >
> >
> > State before running command: 9 Modified files, 2 (new) untracked 
> > files
> >
> > Note: I only wanted to commit some of the modified files (essentially 
> > all the files/changes I wanted to commit were in one directory)
> >
> > Actual command run:  git stash push -u -- Directory/To/Files/* -m "My Message"
> >
> > Returned:
> >
> >     Saved working directory and index state WIP on [BranchName]: [Commit hash] [Commit Message]
> >     fatal: pathspec '-m' did not match any files
> >     error: unrecognized input
> >
> > State after Command ran: 9 Modifed files, 0 untracked files
> >
> >
> > The command I should have ran should have been
> >
> >     git stash push -u -m "My Message"? -- Directory/To/Files/*
> >
> >
> > I have found the stash that was created by running this command:
> >
> >     gitk --all $(git fsck --no-reflog | Select-String "(dangling 
> > commit )(.*)" | %{ $_.Line.Split(' ')[2] }) ?
> > and searching for the commit number that was returned from the original (paritally failed??) stash command. However there is nothing in that stash. It is empty.
> >
> >
> >
> > I think that the fact my untracked files were lost is not correct 
> > behaviour and hence why I'm filing this bug report
> >
> >
> >
> >
> > ________________________________
> > NOTICE: This message, and any attachments, are for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at E-Communication Disclaimer<http://www.cmegroup.com/tools-information/communications/e-communication-disclaimer.html>. If you are not the intended recipient, please delete this message. CME Group and its subsidiaries reserve the right to monitor all email communications that occur on CME Group information systems.