Re: Bug when stashing previously-ignored file plus associated .gitignore change

[Sam Partington]

Hello Kevin,

Yes, you're right - I didn't commit the change to the .gitignore file,
so that addition is also being stashed.

Thanks
Sam
Sam Partington
Senior Developer



www.whiteoctober.co.uk
Office: +44 (0)1865 920 707

This email message and any attachments are confidential and solely for
the use of the intended recipient. If you are not the intended
recipient, you have received this message in error. Please notify us
immediately and delete the message from your computer. You should not
distribute, copy or disclose its contents to any other person. Any
views or opinions expressed in this email are solely those of the
author and do not necessarily represent those of White October
Limited. White October is a private limited company registered in
England & Wales under registration number 3982889. The company’s
registered office is at 264 Banbury Road, Oxford, OX2 7DY.


On 14 August 2017 at 05:47, Kevin Daudt  wrote:
> On Fri, Aug 11, 2017 at 04:55:38PM +0100, Sam Partington wrote:
>> Hi there,
>>
>> I'm running git 2.7.4 on Ubuntu 16.04.  I've found a couple of
>> problems when "un-ignoring" files in tandem with git stash.
>>
>> Here's how to reproduce:
>>
>> Say you have a project using git, with a .gitignore file which
>> contains the following line:
>>
>> bin/*
>>
>> You can then see the problems by doing this:
>>
>> $ touch bin/mynewfile # this file will be ignored at this point >
>> and then updating .gitignore to look like this (adding that second line):
>>
>> bin/*
>> !bin/mynewfile
>>
>> So far, so good; the new file is no longer ignored.
>>
>> But now, try stashing the changes and including untracked files in the stash:
>>
>> $ git stash save -u
>>
>> Here's the first problem, bin/mynewfile is still there:
>>
>> $ ls bin/mynewfile
>> bin/mynewfile
>>
>> But you'd expect it to not be there and be in the stash, I think.
>> This is what would normally happen with the untracked-files option for
>> git stash.
>>
>> This leads to the second problem - you can't now pop the stash:
>>
>> $ git stash pop
>> bin/mynewfile already exists, no checkout
>> Could not restore untracked files from stash
>>
>> If you want to apply the stash, you have to remove the file:
>>
>> $ rm bin/mynewfile
>> $ git stash pop # this works, and re-creates bin/mynewfile
>>
>> This is quite an unusual edge case, but I have hit it two or three
>> times now and so thought it worth reporting, but I'll understand if
>> it's deemed not worth fixing!
>>
>> Do let me know if you need any more information from me here.
>>
>> Thanks
>> Sam
>>
>> PS Sorry for the lack of formatting - I'm sending this as plain text
>> as my original HTML emails was rejected as possible spam by your
>> mailserver.
>>
>> Sam Partington
>> Senior Developer
>>
>
> Hello Sam,
>
> Is it the case that you did not commit the addition of '!bin/mynewfile'
> yet? I suspect that by running git stash save -u, you also are stashing
> this addition to the .gitigore file. Can you confirm this?
>
> Kevin

Re: Bug when stashing previously-ignored file plus associated .gitignore change

[Kevin Daudt]

On Fri, Aug 11, 2017 at 04:55:38PM +0100, Sam Partington wrote:
> Hi there,
> 
> I'm running git 2.7.4 on Ubuntu 16.04.  I've found a couple of
> problems when "un-ignoring" files in tandem with git stash.
> 
> Here's how to reproduce:
> 
> Say you have a project using git, with a .gitignore file which
> contains the following line:
> 
> bin/*
> 
> You can then see the problems by doing this:
> 
> $ touch bin/mynewfile # this file will be ignored at this point > 
> and then updating .gitignore to look like this (adding that second line):
> 
> bin/*
> !bin/mynewfile
> 
> So far, so good; the new file is no longer ignored.
> 
> But now, try stashing the changes and including untracked files in the stash:
> 
> $ git stash save -u
> 
> Here's the first problem, bin/mynewfile is still there:
> 
> $ ls bin/mynewfile
> bin/mynewfile
> 
> But you'd expect it to not be there and be in the stash, I think.
> This is what would normally happen with the untracked-files option for
> git stash.
> 
> This leads to the second problem - you can't now pop the stash:
> 
> $ git stash pop
> bin/mynewfile already exists, no checkout
> Could not restore untracked files from stash
> 
> If you want to apply the stash, you have to remove the file:
> 
> $ rm bin/mynewfile
> $ git stash pop # this works, and re-creates bin/mynewfile
> 
> This is quite an unusual edge case, but I have hit it two or three
> times now and so thought it worth reporting, but I'll understand if
> it's deemed not worth fixing!
> 
> Do let me know if you need any more information from me here.
> 
> Thanks
> Sam
> 
> PS Sorry for the lack of formatting - I'm sending this as plain text
> as my original HTML emails was rejected as possible spam by your
> mailserver.
> 
> Sam Partington
> Senior Developer
> 

Hello Sam,

Is it the case that you did not commit the addition of '!bin/mynewfile'
yet? I suspect that by running git stash save -u, you also are stashing
this addition to the .gitigore file. Can you confirm this?

Kevin

Bug when stashing previously-ignored file plus associated .gitignore change

[Sam Partington]

Hi there,

I'm running git 2.7.4 on Ubuntu 16.04.  I've found a couple of
problems when "un-ignoring" files in tandem with git stash.

Here's how to reproduce:

Say you have a project using git, with a .gitignore file which
contains the following line:

bin/*

You can then see the problems by doing this:

$ touch bin/mynewfile # this file will be ignored at this point

and then updating .gitignore to look like this (adding that second line):

bin/*
!bin/mynewfile

So far, so good; the new file is no longer ignored.

But now, try stashing the changes and including untracked files in the stash:

$ git stash save -u

Here's the first problem, bin/mynewfile is still there:

$ ls bin/mynewfile
bin/mynewfile

But you'd expect it to not be there and be in the stash, I think.
This is what would normally happen with the untracked-files option for
git stash.

This leads to the second problem - you can't now pop the stash:

$ git stash pop
bin/mynewfile already exists, no checkout
Could not restore untracked files from stash

If you want to apply the stash, you have to remove the file:

$ rm bin/mynewfile
$ git stash pop # this works, and re-creates bin/mynewfile

This is quite an unusual edge case, but I have hit it two or three
times now and so thought it worth reporting, but I'll understand if
it's deemed not worth fixing!

Do let me know if you need any more information from me here.

Thanks
Sam

PS Sorry for the lack of formatting - I'm sending this as plain text
as my original HTML emails was rejected as possible spam by your
mailserver.

Sam Partington
Senior Developer

www.whiteoctober.co.uk
Office: +44 (0)1865 920 707

This email message and any attachments are confidential and solely for
the use of the intended recipient. If you are not the intended
recipient, you have received this message in error. Please notify us
immediately and delete the message from your computer. You should not
distribute, copy or disclose its contents to any other person. Any
views or opinions expressed in this email are solely those of the
author and do not necessarily represent those of White October
Limited. White October is a private limited company registered in
England & Wales under registration number 3982889. The company’s
registered office is at 264 Banbury Road, Oxford, OX2 7DY.