Jeff King writes:
>> > Hrm. The problem is that after creating the stash, we then run "git
>> > reset --hard" to drop the changes that we just stashed. But that is not
>> > always accurate. It will not usually touch untracked files, but it might
>> > if they have D/F conflicts with tracked files.
On Thu, Aug 16, 2012 at 08:30:48PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, Jul 27, 2012 at 09:29:53AM -0400, Jeff King wrote:
> >
> >> If we put actual files inside "x", which git does track, then they would
> >> be part of the stash, and should be properly retained. But t
Jeff King writes:
> On Fri, Jul 27, 2012 at 09:29:53AM -0400, Jeff King wrote:
>
>> If we put actual files inside "x", which git does track, then they would
>> be part of the stash, and should be properly retained. But they're not:
>>
>> $ rm x && mkdir x && echo foo >x/file
>>
>> Now we have
Thanks Jeff for the comment. You are right. I oversimplified the use-case (
forget to fill the directory )
Sent from my iPad
On Jul 27, 2012, at 5:29 PM, Jeff King wrote:
> On Fri, Jul 27, 2012 at 07:06:08AM +0400, Aleksandr Pryimak wrote:
>
>> I also recreated it
>>
>> aleksandr@beast:/tmp/
On Fri, Jul 27, 2012 at 09:29:53AM -0400, Jeff King wrote:
> If we put actual files inside "x", which git does track, then they would
> be part of the stash, and should be properly retained. But they're not:
>
> $ rm x && mkdir x && echo foo >x/file
>
> Now we have some precious contents in th
On Fri, Jul 27, 2012 at 07:06:08AM +0400, Aleksandr Pryimak wrote:
> I also recreated it
>
> aleksandr@beast:/tmp/test$ git init
> Initialized empty Git repository in /tmp/test/.git/
> aleksandr@beast:/tmp/test$ touch x
> aleksandr@beast:/tmp/test$ git add x
> aleksandr@beast:/tmp/test$ git commi
6 matches
Mail list logo
