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

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