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
next prev parent 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).