From: Neil Macneale <mac4-git@theory.org>
To: git <git@vger.kernel.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: Stashing untracked files
Date: Sat, 29 Sep 2007 20:59:26 -0700 [thread overview]
Message-ID: <46FF1F1E.2050000@theory.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0709292259070.28395@racer.site>
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
next prev parent reply other threads:[~2007-09-30 3:59 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
2007-09-29 22:00 ` Johannes Schindelin
2007-09-30 3:59 ` Neil Macneale [this message]
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=46FF1F1E.2050000@theory.org \
--to=mac4-git@theory.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
/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).