git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Macneale <mac4-git@theory.org>
To: git <git@vger.kernel.org>
Cc: Benoit SIGOURE <tsuna@lrde.epita.fr>
Subject: Re: Stashing untracked files
Date: Sat, 29 Sep 2007 14:46:01 -0700	[thread overview]
Message-ID: <46FEC799.30803@theory.org> (raw)
In-Reply-To: <EEE8F630-AE62-4425-96A0-239D54724DF4@lrde.epita.fr>

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

  reply	other threads:[~2007-09-29 21:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-29 18:27 Stashing untracked files Neil Macneale
2007-09-29 21:03 ` Johannes Schindelin
2007-09-29 21:10   ` Benoit SIGOURE
2007-09-29 21:46     ` Neil Macneale [this message]
2007-09-29 22:00       ` Johannes Schindelin
2007-09-30  3:59         ` Neil Macneale
2007-09-30  8:41           ` Steffen Prohaska
2007-09-30 13:18           ` Wincent Colaiuta
2007-09-29 21:51     ` Johannes Schindelin
2007-09-29 22:23       ` Tom Prince
2007-09-29 23:09         ` Johannes Schindelin
2007-09-30 20:44 ` Tom Tobin
2007-09-30 21:25   ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46FEC799.30803@theory.org \
    --to=mac4-git@theory.org \
    --cc=git@vger.kernel.org \
    --cc=tsuna@lrde.epita.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).