Stashing untracked files

Stashing untracked files

[Neil Macneale]

Hi All,

I'm new to git, and I have a question regarding the best way to do 
something.

When using "git stash," in some cases I'd like to stash away files that 
are currently untracked. It seems to me like there should be a way to 
stash everything in a working directory so that the end result is a 
pristine tree. Then applying the stash will reinstate those file as 
untracked.

I understand that is not always desired, but sometimes it is (for me 
anyway). Perhaps an option like "git stash -u" could provide this behavior?

Is there some other approach that makes more sense? I don't want to 
start looking into this until I have some idea if this is a sane idea :-)

Thanks,
Neil

Re: Stashing untracked files

[Johannes Schindelin]

Hi,

On Sat, 29 Sep 2007, Neil Macneale wrote:

> When using "git stash," in some cases I'd like to stash away files that 
> are currently untracked. It seems to me like there should be a way to 
> stash everything in a working directory so that the end result is a 
> pristine tree. Then applying the stash will reinstate those file as 
> untracked.

Funny how the same ideas always come in packs: I had the same discussions 
a few nights ago on IRC.

Here is why I think it is _wrong_ to stash untracked files: this would 
include *.o and *.a, as well as all those binary files, too.

Instead this is what you _should_ do:

git add <the files that you care about>
git stash

Hth,
Dscho

Re: Stashing untracked files

[Benoit SIGOURE]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

On Sep 29, 2007, at 11:03 PM, Johannes Schindelin wrote:

> Hi,
>
> On Sat, 29 Sep 2007, Neil Macneale wrote:
>
>> When using "git stash," in some cases I'd like to stash away files  
>> that
>> are currently untracked. It seems to me like there should be a way to
>> stash everything in a working directory so that the end result is a
>> pristine tree. Then applying the stash will reinstate those file as
>> untracked.
>
> Funny how the same ideas always come in packs: I had the same  
> discussions
> a few nights ago on IRC.
>
> Here is why I think it is _wrong_ to stash untracked files: this would
> include *.o and *.a, as well as all those binary files, too.
>
> Instead this is what you _should_ do:
>
> git add <the files that you care about>
> git stash

You could stash untracked files that are not ignored (I personally  
ignore *.o, *.a and the like).

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: Stashing untracked files

[Neil Macneale]

Benoit SIGOURE wrote:
> On Sep 29, 2007, at 11:03 PM, Johannes Schindelin wrote:
> 
>> Hi,
>>
>> On Sat, 29 Sep 2007, Neil Macneale wrote:
>>
>>> When using "git stash," in some cases I'd like to stash away files that
>>> are currently untracked. It seems to me like there should be a way to
>>> stash everything in a working directory so that the end result is a
>>> pristine tree. Then applying the stash will reinstate those file as
>>> untracked.
>>
>> Funny how the same ideas always come in packs: I had the same discussions
>> a few nights ago on IRC.
>>
>> Here is why I think it is _wrong_ to stash untracked files: this would
>> include *.o and *.a, as well as all those binary files, too.
>>
>> Instead this is what you _should_ do:
>>
>> git add <the files that you care about>
>> git stash
> 
> You could stash untracked files that are not ignored (I personally 
> ignore *.o, *.a and the like).
> 
Yeah, I wouldn't want the ignored files. I'm interested in the files 
listed as untracked when I run git status.

Performing an add would require me to remove those file from the index 
at a later date in the event that I don't want to commit them on the 
next commit.

In the case I'm dealing with right now, I working on content files 
(html/perl). It's not uncommon for me to have files which are untracked 
and will remain that way for an extended period of time (a few commits, 
say). When I need to do a stash, I generally don't want those files 
around afterward.

( Here is the full story. I'm using git to make my life working with 
perforce a little less painful. It's not uncommon for me to jump to my 
master branch to do a perforce sync. When I do that, I want all of my 
changes in working branches stashed away. I selectively add new files on 
each commit so that what is committed to the working branch syncs up 
with what I end up submitting to perforce. And to make my life even more 
difficult, my co-workers are not using git. So it's not uncommon for 
someone to send me a file for my sandbox which I will never submit to 
perforce because it's their job to do so. I can't tell you how many 
times I've told them "this would be a lot easier if we all just used 
git" but I digress... )

Thanks,
Neil

Re: Stashing untracked files

[Johannes Schindelin]

Hi,

On Sat, 29 Sep 2007, Benoit SIGOURE wrote:

> On Sep 29, 2007, at 11:03 PM, Johannes Schindelin wrote:
> 
> > Instead this is what you _should_ do:
> > 
> > git add <the files that you care about>
> > git stash
> 
> You could stash untracked files that are not ignored (I personally 
> ignore *.o, *.a and the like).

And what if you happen to forget to ignore that?  Or if you happen to 
have an strace log in some file (which you did not ignore either)?

Thanks, but I think the semantics of git stash is pretty well defined.  
And it means that you stash away _tracked_ content that was not yet 
committed.

I mean, you can have your desired behaviour with

$ git add .
$ git stash

but if we were to fulfil your wish and change the default behaviour, there 
is no way back to the current behaviour (which I happen to find pretty 
sane).

Ciao,
Dscho

Re: Stashing untracked files

[Johannes Schindelin]

Hi,

[please do not cull me from the Cc: list, especially if you quote me.]

On Sat, 29 Sep 2007, Neil Macneale wrote:

> Performing an add would require me to remove those file from the index 
> at a later date in the event that I don't want to commit them on the 
> next commit.

Wrong.

If you "git add <new-file>" and then "git stash", it will no longer have 
the file in the index.  Instead, the index will agree with the HEAD (which 
does not have <new-file>).

Ciao,
Dscho

Re: Stashing untracked files

[Tom Prince]

> > You could stash untracked files that are not ignored (I personally 
> > ignore *.o, *.a and the like).
> 
> And what if you happen to forget to ignore that?  Or if you happen to 
> have an strace log in some file (which you did not ignore either)?
> 
> Thanks, but I think the semantics of git stash is pretty well defined.  
> And it means that you stash away _tracked_ content that was not yet 
> committed.
> 
> I mean, you can have your desired behaviour with
> 
> $ git add .
> $ git stash
> 
> but if we were to fulfil your wish and change the default behaviour, there 
> is no way back to the current behaviour (which I happen to find pretty 
> sane).

But

git add .
git stash
git stash apply

will not be a no-op any more.

It doesn't need to be a default, but there are certainly times when I would
find the option to stash untracked files convenient.

  Tom

Re: Stashing untracked files

[Johannes Schindelin]

Hi,

On Sat, 29 Sep 2007, Tom Prince wrote:

> > > You could stash untracked files that are not ignored (I personally 
> > > ignore *.o, *.a and the like).
> > 
> > And what if you happen to forget to ignore that?  Or if you happen to 
> > have an strace log in some file (which you did not ignore either)?
> > 
> > Thanks, but I think the semantics of git stash is pretty well defined.  
> > And it means that you stash away _tracked_ content that was not yet 
> > committed.
> > 
> > I mean, you can have your desired behaviour with
> > 
> > $ git add .
> > $ git stash
> > 
> > but if we were to fulfil your wish and change the default behaviour, 
> > there is no way back to the current behaviour (which I happen to find 
> > pretty sane).
> 
> But
> 
> git add .
> git stash
> git stash apply
> 
> will not be a no-op any more.

It never was.  (Or did you mean "git stash apply --index"?)

> It doesn't need to be a default, but there are certainly times when I 
> would find the option to stash untracked files convenient.

But then I'll have to ask you why the untracked files, which are not 
touched by git, have to be stashed anyway?

I'm seriously thinking that we are in deep "XY problem" land here.

Ciao,
Dscho

Re: Stashing untracked files

[Neil Macneale]

Johannes Schindelin wrote:
> Hi,
> 
> [please do not cull me from the Cc: list, especially if you quote me.]
> 
> On Sat, 29 Sep 2007, Neil Macneale wrote:
> 
>> Performing an add would require me to remove those file from the index 
>> at a later date in the event that I don't want to commit them on the 
>> next commit.
> 
> Wrong.
> 
> If you "git add <new-file>" and then "git stash", it will no longer have 
> the file in the index.  Instead, the index will agree with the HEAD (which 
> does not have <new-file>).
> 
> Ciao,
> Dscho

To be a little more clear, this is why I'd like to stash untracked files.

$ <hack hack>    # source tree is a mess
$ git stash -u   # stash everything, even untracked files. I never
                  # suggesting modifying the default behavior.
$ <fix bug>
$ git commit -a
$ git stash apply
$ hack some more
$ git add file1 file2  # I'm ready for some things to be committed,
                        # but my source tree is still a mess.
$ git commit

To do what you are suggesting would be something like this (correct me 
if I'm wrong):

$ <hack hack>
$ git add .      # Additional step, not a big deal.
$ git stash
$ <fix bug>
$ git commit -a
$ git stash apply
$ git reset HEAD <all file I don't actually need to add but was forced
                   to add in step above.>
                  # What concerns me is that I may not reset some files
                  # that need to be reset, or reset other ones which
                  # should not be reset. This is the headache I want to
                  # avoid.
$ <hack hack>
$ git add file1 file2
$ git commit

git stash is an acknowledgment that not everything needs to be 
committed, and sometimes working source trees are messy. Prior to the 
stash command, I just accepted that I'd need to commit everything and do 
  some maintenance to un-commit those changes. stash is awesome for me 
and the realities of the way I need to work. IMHO, it would be the best 
thing since sliced bread if it handled untracked files.

If this is really just a problem for me, I can write a shell script to 
do the dirty work. I just wonder if it is a common enough use case that 
it merits support in the tool itself.

Cheers,
Neil

Re: Stashing untracked files

[Steffen Prohaska]

On Sep 30, 2007, at 5:59 AM, Neil Macneale wrote:

> git stash is an acknowledgment that not everything needs to be  
> committed, and sometimes working source trees are messy. Prior to  
> the stash command, I just accepted that I'd need to commit  
> everything and do  some maintenance to un-commit those changes.  
> stash is awesome for me and the realities of the way I need to  
> work. IMHO, it would be the best thing since sliced bread if it  
> handled untracked files.

I agree, it could be a great tool. Even only to make me feel better
before running 'git clean' on a larger source tree when I was to
lazy to scan 'git clean -n' in detail.

BTW, I don't have results of the builds in my work tree but keep
them in a separate directory. Nearly everything in the work tree
is 'real' source code, maybe cluttered with some backups or tmp files.


> If this is really just a problem for me, I can write a shell script  
> to do the dirty work. I just wonder if it is a common enough use  
> case that it merits support in the tool itself.

I think it would be useful. Here is a problem I ran into last week:

A merge failed because it wanted to add a file not tracked by
the current branch. At first I didn't fully appreciate this fact
and thought that 'git stash' could help. But to do so, it would
need to store the _untracked_ file and remove it from the work tree.
This would allow the merge to succeed. Current stash didn't really
help.

	Steffen

Re: Stashing untracked files

[Wincent Colaiuta]

El 30/9/2007, a las 5:59, Neil Macneale escribió:

> $ git stash -u   # stash everything, even untracked files. I never
>                  # suggesting modifying the default behavior.

Provided it's not the default behaviour, and provided that it doesn't  
add ignored files, this sounds perfectly reasonable and potentially  
quite useful.

I say *potentially* only because I've yet to find a situation wherein  
I can't just do the following:

<hack>                # lots of untracked files floating around
$ git stash           # untracked files stay exactly where they were
<orthogonal hacking>  # untracked files still there
$ git stash apply     # still there...
<hack>                # still there...

If the content of the untracked files is both, (a) important and (b)  
being modified over time, then perhaps it should be being tracked.

Wincent

Re: Stashing untracked files

[Tom Tobin]

On 9/29/07, Neil Macneale <mac4-git@theory.org> wrote:
> When using "git stash," in some cases I'd like to stash away files that
> are currently untracked. It seems to me like there should be a way to
> stash everything in a working directory so that the end result is a
> pristine tree. Then applying the stash will reinstate those file as
> untracked.

Since this is an itch of my own, I have a local copy of git-stash that
does this (stashes away the untracked -- but not ignored -- files, and
restores them as untracked upon "stash apply"); unfortunately, I'm
pretty new to git, so I'm certain my code is *quite* unoptimized and
ugly.  As soon as I feel comfortable with it (which should include
making the new behavior optional), I'll drop a line here with some
code.  :-)

Re: Stashing untracked files

[Johannes Schindelin]

Hi,

On Sun, 30 Sep 2007, Tom Tobin wrote:

> On 9/29/07, Neil Macneale <mac4-git@theory.org> wrote:
> > When using "git stash," in some cases I'd like to stash away files 
> > that are currently untracked. It seems to me like there should be a 
> > way to stash everything in a working directory so that the end result 
> > is a pristine tree. Then applying the stash will reinstate those file 
> > as untracked.
> 
> Since this is an itch of my own, I have a local copy of git-stash that 
> does this (stashes away the untracked -- but not ignored -- files, and 
> restores them as untracked upon "stash apply"); unfortunately, I'm 
> pretty new to git, so I'm certain my code is *quite* unoptimized and 
> ugly.  As soon as I feel comfortable with it (which should include 
> making the new behavior optional), I'll drop a line here with some code.  
> :-)

We are known on this list for never biting someone's head off, especially 
not when posting patches.

Why not just post it, see what comments come back, adapt it, and repost?  
More often than not, people learn by getting their code reviewed, and 
faster so when the code is reviewed early.

Ciao,
Dscho