Stashing untracked files

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

Hi,

On Sat, 29 Sep 2007, Neil Macneale wrote:

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

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

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

Benoit SIGOURE wrote:

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

Hi,

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

On Sat, 29 Sep 2007, Neil Macneale wrote:

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

Johannes Schindelin wrote:

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

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

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.

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

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

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

Hi,

On Sat, 29 Sep 2007, Benoit SIGOURE wrote:

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

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

Hi,

On Sat, 29 Sep 2007, Tom Prince wrote:

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

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

On 9/29/07, Neil Macneale <mac4-git@theory.org> wrote:

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. :-)

Hi,

On Sun, 30 Sep 2007, Tom Tobin wrote:

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