* Re: [PATCH] stash: Add --clean option to stash and remove all untracked files
@ 2011-06-22 5:49 David Caldwell
0 siblings, 0 replies; 12+ messages in thread
From: David Caldwell @ 2011-06-22 5:49 UTC (permalink / raw)
To: Marc Branchaud, Paul Ebermann
Cc: git, Jeff King, Johannes Sixt, Andrew Wong, Junio C Hamano
On 6/21/11 5:23 PM -0400 Marc Branchaud wrote:
> On 11-06-21 12:11 PM, Paul Ebermann wrote:
>>
>> I think `--also-untracked` sounds better. It is even longer, though.
>>
>> There could also be `--only-untracked`, which would stack only the
>> untracked files (and let changes of tracked files there).
>
> Perhaps -uall to match git-status's -u[<mode>] option (and also the long
> version thereof)?
Currently I'm playing with --include-untracked (-u) and --all (-a) while I
fix a bug I found in the patch. I agree that --untracked sounds like it's
only stashing the untracked files which isn't the case. I wasn't going to
have an option to stash *just* the untracked files because I can't come up
with a use case that makes sense. I still like "--clean", too.
-uall (like git status) isn't really the same thing which I think is
confusing since it has the same name.
-David
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] stash: Add --clean option to stash and remove all untracked files
@ 2011-06-20 23:36 David Caldwell
2011-06-21 0:38 ` Jeff King
0 siblings, 1 reply; 12+ messages in thread
From: David Caldwell @ 2011-06-20 23:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, David Caldwell
The --clean option acts like the normal "git stash save" but also adds all
untracked files in the working directory to the stash and then calls "git
clean --force --quiet" to restore the working directory to a pristine
state.
I find this useful for certain projects that need to run release
scripts. With this option I can run the release scripts from my main working
directory and not have to maintain a "clean" directory in parallel just for
releasing. Basically the work-flow becomes:
$ git tag release-1.0
$ git stash --clean
$ make release
$ git stash pop
"git stash" alone is not enough in this case--it leaves untracked files
lying around (configure and automake droppings, for instance) that might
mess up a release process that expects everything to be very clean.
Signed-off-by: David Caldwell <david@porkrind.org>
Hi,
This is my first patch to git so I have a couple questions:
* I used 'find . -name ".git" -prune -o -print' to get a list of all the
files in the working directory. That assumes ".git" is the name
of the repo--is that assumption valid?
* Also, that find command does not respect .gitignore. Should it? If it
does then I think it would need another option to also clean up stuff
that is normally ignored (similar to the way "git clean" works with the
-x option). My thoughts were that if we were stashing everything, being
overzealous with the cleanup wouldn't hurt (and would generally be
exactly what you want).
Thanks,
David
---
Documentation/git-stash.txt | 8 ++-
git-stash.sh | 20 +++++++-
t/t3905-stash-clean.sh | 111 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 134 insertions(+), 5 deletions(-)
create mode 100755 t/t3905-stash-clean.sh
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 15f051f..7c9055c 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -13,7 +13,7 @@ SYNOPSIS
'git stash' drop [-q|--quiet] [<stash>]
'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>]
'git stash' branch <branchname> [<stash>]
-'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] [<message>]]
+'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-c|--clean] [-q|--quiet] [<message>]]
'git stash' clear
'git stash' create
@@ -42,7 +42,7 @@ is also possible).
OPTIONS
-------
-save [-p|--patch] [--[no-]keep-index] [-q|--quiet] [<message>]::
+save [-p|--patch] [--[no-]keep-index] [-c|--clean] [-q|--quiet] [<message>]::
Save your local modifications to a new 'stash', and run `git reset
--hard` to revert them. The <message> part is optional and gives
@@ -54,6 +54,10 @@ save [-p|--patch] [--[no-]keep-index] [-q|--quiet] [<message>]::
If the `--keep-index` option is used, all changes already added to the
index are left intact.
+
+If the `--clean` option is used, all non-tracked files are also stashed and
+then cleaned up with `git clean`, leaving the working directory in a very
+clean state.
++
With `--patch`, you can interactively select hunks from the diff
between HEAD and the working tree to be stashed. The stash entry is
constructed such that its index state is the same as the index state
diff --git a/git-stash.sh b/git-stash.sh
index 0a94036..ea34dc4 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -7,7 +7,7 @@ USAGE="list [<options>]
or: $dashless drop [-q|--quiet] [<stash>]
or: $dashless ( pop | apply ) [--index] [-q|--quiet] [<stash>]
or: $dashless branch <branchname> [<stash>]
- or: $dashless [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] [<message>]]
+ or: $dashless [save [--patch] [-k|--[no-]keep-index] [-c|--clean] [-q|--quiet] [<message>]]
or: $dashless clear"
SUBDIRECTORY_OK=Yes
@@ -49,6 +49,7 @@ clear_stash () {
create_stash () {
stash_msg="$1"
+ clean="$2"
git update-index -q --refresh
if no_changes
@@ -86,7 +87,7 @@ create_stash () {
git read-tree --index-output="$TMPindex" -m $i_tree &&
GIT_INDEX_FILE="$TMPindex" &&
export GIT_INDEX_FILE &&
- git diff --name-only -z HEAD | git update-index -z --add --remove --stdin &&
+ (git diff --name-only -z HEAD; test -n "$clean" && find . -name ".git" -prune -o -print0) | git update-index -z --add --remove --stdin &&
git write-tree &&
rm -f "$TMPindex"
) ) ||
@@ -129,6 +130,7 @@ create_stash () {
save_stash () {
keep_index=
patch_mode=
+ clean=
while test $# != 0
do
case "$1" in
@@ -146,6 +148,9 @@ save_stash () {
-q|--quiet)
GIT_QUIET=t
;;
+ -c|--clean)
+ clean=t
+ ;;
--)
shift
break
@@ -162,6 +167,11 @@ save_stash () {
shift
done
+ if test -n "$patch_mode" && test -n "$clean"
+ then
+ die "Can't stash --patch and --clean at the same time"
+ fi
+
stash_msg="$*"
git update-index -q --refresh
@@ -173,7 +183,7 @@ save_stash () {
test -f "$GIT_DIR/logs/$ref_stash" ||
clear_stash || die "Cannot initialize stash"
- create_stash "$stash_msg"
+ create_stash "$stash_msg" $clean
# Make sure the reflog for stash is kept.
: >>"$GIT_DIR/logs/$ref_stash"
@@ -185,6 +195,10 @@ save_stash () {
if test -z "$patch_mode"
then
git reset --hard ${GIT_QUIET:+-q}
+ if test -n "$clean"
+ then
+ git clean --force --quiet
+ fi
if test "$keep_index" = "t" && test -n $i_tree
then
diff --git a/t/t3905-stash-clean.sh b/t/t3905-stash-clean.sh
new file mode 100755
index 0000000..301e4b0
--- /dev/null
+++ b/t/t3905-stash-clean.sh
@@ -0,0 +1,111 @@
+#!/bin/sh
+#
+# Copyright (c) 2011 David Caldwell
+#
+
+test_description='Test git stash --clean'
+
+. ./test-lib.sh
+
+# Test code doesn't seem to clean the test dir out between runs.
+#git clean --force --quiet
+
+test_expect_success 'stash save --clean some dirty working directory' '
+ echo 1 > file &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+ echo 2 > file &&
+ git add file &&
+ echo 3 > file &&
+ test_tick &&
+ echo 1 > file2 &&
+ git stash --clean &&
+ git diff-files --quiet &&
+ git diff-index --cached --quiet HEAD
+'
+
+cat > expect <<EOF
+?? expect
+?? output
+EOF
+
+test_expect_success 'stash save --clean cleaned the untracked files' '
+ git status --porcelain > output
+ test_cmp output expect
+'
+
+cat > expect << EOF
+diff --git a/file b/file
+index 0cfbf08..00750ed 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-2
++3
+diff --git a/file2 b/file2
+new file mode 100644
+index 0000000..d00491f
+--- /dev/null
++++ b/file2
+@@ -0,0 +1 @@
++1
+EOF
+
+test_expect_success 'stash save --clean stashed the untracked files' '
+ git diff stash^2..stash > output &&
+ test_cmp output expect
+'
+
+test_expect_success 'stash save --patch --clean fails' '
+ test_must_fail git stash --patch --clean
+'
+
+git clean --force --quiet
+
+test_expect_success 'stash save -c dirty index' '
+ echo 4 > file3 &&
+ git add file3 &&
+ test_tick &&
+ git stash -c
+'
+
+cat > expect <<EOF
+diff --git a/file3 b/file3
+new file mode 100644
+index 0000000..b8626c4
+--- /dev/null
++++ b/file3
+@@ -0,0 +1 @@
++4
+EOF
+
+test_expect_success 'stash save --clean dirty index got stashed' '
+ git stash pop --index &&
+ git diff --cached > output &&
+ test_cmp output expect
+'
+
+git reset
+
+test_expect_success 'stash save --clean -q is quiet' '
+ echo 1 > file5
+ git stash save --clean --quiet > output.out 2>&1 &&
+ test ! -s output.out
+'
+
+test_expect_success 'stash save --clean removed files' '
+ rm -f file &&
+ git stash save --clean &&
+ echo 1 > expect &&
+ test_cmp file expect
+'
+
+rm -f expect
+
+test_expect_success 'stash save --clean removed files got stashed' '
+ git stash pop &&
+ test ! -f file
+'
+
+test_done
--
1.7.5.3
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] stash: Add --clean option to stash and remove all untracked files
2011-06-20 23:36 David Caldwell
@ 2011-06-21 0:38 ` Jeff King
2011-06-21 1:36 ` David Caldwell
0 siblings, 1 reply; 12+ messages in thread
From: Jeff King @ 2011-06-21 0:38 UTC (permalink / raw)
To: David Caldwell; +Cc: git, Junio C Hamano
On Mon, Jun 20, 2011 at 04:36:26PM -0700, David Caldwell wrote:
> The --clean option acts like the normal "git stash save" but also adds all
> untracked files in the working directory to the stash and then calls "git
> clean --force --quiet" to restore the working directory to a pristine
> state.
Hmm. I think I would call this something like "--untracked", as to me
the main function is saving those files, not cleaning them afterwards
(the fact that they are cleaned is really just making the untracked-file
handling in line with what we do for tracked files; we put the changes
in the stash and remove them from the working tree).
But that might just be me.
> I find this useful for certain projects that need to run release
> scripts. With this option I can run the release scripts from my main working
> directory and not have to maintain a "clean" directory in parallel just for
> releasing. Basically the work-flow becomes:
>
> $ git tag release-1.0
> $ git stash --clean
> $ make release
> $ git stash pop
>
> "git stash" alone is not enough in this case--it leaves untracked files
> lying around (configure and automake droppings, for instance) that might
> mess up a release process that expects everything to be very clean.
For that workflow, do you actually want the files saved and restored
via "stash pop"? That is, aren't those untracked files just useless
cruft that could be regenerated, and you would be just as happy to do:
$ git tag release-1.0
$ git stash
$ git clean
$ make release
$ git stash pop
and have a pristine state after your pop? You end up regenerating them
during the next build, which could be costly. But you don't have to pay
the price of stashing potentially large files that are just going to end
up regenerated anyway. For that matter, what should this do with
gitignored files, like generated object files?
Also, wouldn't you want to "git clean" after your "make release" but
before your "git stash pop" in case the build creates cruft that is not
overwritten by your stash pop?
> Signed-off-by: David Caldwell <david@porkrind.org>
>
> Hi,
>
> This is my first patch to git so I have a couple questions:
Hi David. Welcome to the list. :)
Please put your comments on the patch (i.e., anything not destined to go
into the commit message) below the "---" marker; that helps "git am"
know which part is which.
> * I used 'find . -name ".git" -prune -o -print' to get a list of all the
> files in the working directory. That assumes ".git" is the name
> of the repo--is that assumption valid?
Generally yes, but somebody could do something tricky with GIT_DIR. You
should be using "git ls-files -o" instead.
> * Also, that find command does not respect .gitignore. Should it? If it
> does then I think it would need another option to also clean up stuff
> that is normally ignored (similar to the way "git clean" works with the
> -x option). My thoughts were that if we were stashing everything, being
> overzealous with the cleanup wouldn't hurt (and would generally be
> exactly what you want).
I'm not sure of the answer to this. I think it would depend on your
workflow and your project (i.e., is your build system fragile enough
that you need to get rid of ignored build products between builds, or is
it OK to leave them, which is more efficient). I would think respecting
ignore would be a sane default, but I don't know if it should be
configurable, or have an extra command line option to stash everything.
If you do want to respect .gitignore, then you can add
"--exclude-standard" to the "ls-files" command I mentioned above.
> @@ -86,7 +87,7 @@ create_stash () {
> git read-tree --index-output="$TMPindex" -m $i_tree &&
> GIT_INDEX_FILE="$TMPindex" &&
> export GIT_INDEX_FILE &&
> - git diff --name-only -z HEAD | git update-index -z --add --remove --stdin &&
> + (git diff --name-only -z HEAD; test -n "$clean" && find . -name ".git" -prune -o -print0) | git update-index -z --add --remove --stdin &&
> git write-tree &&
> rm -f "$TMPindex"
> ) ) ||
When you apply this stash, what does the resulting index look like? Do
the untracked files remain properly untracked? That might be a good
thing to double check in the test script.
-Peff
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] stash: Add --clean option to stash and remove all untracked files
2011-06-21 0:38 ` Jeff King
@ 2011-06-21 1:36 ` David Caldwell
2011-06-21 5:08 ` Andrew Wong
0 siblings, 1 reply; 12+ messages in thread
From: David Caldwell @ 2011-06-21 1:36 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
On 6/20/11 5:38 PM, Jeff King wrote:
> On Mon, Jun 20, 2011 at 04:36:26PM -0700, David Caldwell wrote:
>
>> The --clean option acts like the normal "git stash save" but also adds all
>> untracked files in the working directory to the stash and then calls "git
>> clean --force --quiet" to restore the working directory to a pristine
>> state.
>
> Hmm. I think I would call this something like "--untracked", as to me
> the main function is saving those files, not cleaning them afterwards
> (the fact that they are cleaned is really just making the untracked-file
> handling in line with what we do for tracked files; we put the changes
> in the stash and remove them from the working tree).
I see your point but I thought "--clean" was pretty descriptive of how
the working dir ended up afterward. Maybe "git stash --everything" (or
"--all")?
>> "git stash" alone is not enough in this case--it leaves untracked files
>> lying around (configure and automake droppings, for instance) that might
>> mess up a release process that expects everything to be very clean.
>
> For that workflow, do you actually want the files saved and restored
> via "stash pop"? That is, aren't those untracked files just useless
> cruft that could be regenerated, and you would be just as happy to do:
>
> $ git tag release-1.0
> $ git stash
> $ git clean
> $ make release
> $ git stash pop
>
> and have a pristine state after your pop?
Yes, in that case you are right. My example was poor. I'm more worried
about junk that might actually affect the release but isn't
auto-generated. I'm usually too wary to run "git clean" because of the
random files I have sitting around--todo lists, random patches, new
files I haven't added but are sitting around possibly affecting tests,
things like that. I want them back at some point, but I want the
directory very clean when doing the release just to make sure I have
everything properly committed (so I could, for example, detect the new
source file that I forgot to add and commit).
> Also, wouldn't you want to "git clean" after your "make release" but
> before your "git stash pop" in case the build creates cruft that is not
> overwritten by your stash pop?
Yes, you'd definitely want the git clean before the git stash pop. I
forgot that step.
> Please put your comments on the patch (i.e., anything not destined to go
> into the commit message) below the "---" marker; that helps "git am"
> know which part is which.
Whoops. That was a copy and paste error. Took multiple tries to get git
send-email to work ;-).
>> * I used 'find . -name ".git" -prune -o -print' to get a list of all the
>> files in the working directory. That assumes ".git" is the name
>> of the repo--is that assumption valid?
>
> Generally yes, but somebody could do something tricky with GIT_DIR. You
> should be using "git ls-files -o" instead.
Ah, thanks--I didn't know about that command! I was considering using
"git status --porcelain", but ls-files looks exactly like what I want.
> For that matter, what should this do with gitignored files, like
> generated object files?
>
>> * Also, that find command does not respect .gitignore. Should it?
>
> I'm not sure of the answer to this. I think it would depend on your
> workflow and your project (i.e., is your build system fragile enough
> that you need to get rid of ignored build products between builds, or is
> it OK to leave them, which is more efficient). I would think respecting
> ignore would be a sane default, but I don't know if it should be
> configurable, or have an extra command line option to stash everything.
>
> If you do want to respect .gitignore, then you can add
> "--exclude-standard" to the "ls-files" command I mentioned above.
The more I think about it the more I think you're right that it should
respect .gitignore on the default case and have another option to be
really thorough (even if my build system isn't always fragile, it's
sometimes nice to be overly cautious just for my own paranoid peace of
mind).
Perhaps --clean (or --untracked) respects .gitignore and --all just flat
out does everything?
>> @@ -86,7 +87,7 @@ create_stash () {
>> git read-tree --index-output="$TMPindex" -m $i_tree &&
>> GIT_INDEX_FILE="$TMPindex" &&
>> export GIT_INDEX_FILE &&
>> - git diff --name-only -z HEAD | git update-index -z --add --remove --stdin &&
>> + (git diff --name-only -z HEAD; test -n "$clean" && find . -name ".git" -prune -o -print0) | git update-index -z --add --remove --stdin &&
>> git write-tree &&
>> rm -f "$TMPindex"
>> ) ) ||
>
> When you apply this stash, what does the resulting index look like? Do
> the untracked files remain properly untracked? That might be a good
> thing to double check in the test script.
They do in indeed, but you're right, that would be a good automated test
to add.
Thanks, I greatly appreciate the help.
-David
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] stash: Add --clean option to stash and remove all untracked files
2011-06-21 1:36 ` David Caldwell
@ 2011-06-21 5:08 ` Andrew Wong
2011-06-21 6:28 ` Johannes Sixt
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Wong @ 2011-06-21 5:08 UTC (permalink / raw)
To: David Caldwell; +Cc: Jeff King, git, Junio C Hamano
Ah, this patch will be very useful. I actually ran into several
scenarios before where I wished stash could do exactly this.
On 11-06-20 9:36 PM, David Caldwell wrote:
> On 6/20/11 5:38 PM, Jeff King wrote:
>> Hmm. I think I would call this something like "--untracked", as to me
>> the main function is saving those files, not cleaning them afterwards
>> (the fact that they are cleaned is really just making the untracked-file
>> handling in line with what we do for tracked files; we put the changes
>> in the stash and remove them from the working tree).
>
> I see your point but I thought "--clean" was pretty descriptive of how
> the working dir ended up afterward. Maybe "git stash --everything" (or
> "--all")?
I personally think "--untracked" (and -u) is more intuitive too, since
it tells you what "git stash" is about to do. i.e. "git stash" is about
to do the usual stash operation *and* also stash the "untracked" files.
It seems more clear and precise than saying "git will stash my tree to a
state that is clean", which doesn't exactly tell me how is that
different from the usual stash.To me, "--clean" might even sounds more
like "do a stash, and then do a clean", which doesn't make sense.
I would've liked "--all" too, except it reminds me too much of "git
commit --all", which is just committing all tracked files.
Again, that's just my personal preference.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] stash: Add --clean option to stash and remove all untracked files
2011-06-21 5:08 ` Andrew Wong
@ 2011-06-21 6:28 ` Johannes Sixt
2011-06-21 14:18 ` Jeff King
0 siblings, 1 reply; 12+ messages in thread
From: Johannes Sixt @ 2011-06-21 6:28 UTC (permalink / raw)
To: Andrew Wong; +Cc: David Caldwell, Jeff King, git, Junio C Hamano
Am 6/21/2011 7:08, schrieb Andrew Wong:
> Ah, this patch will be very useful. I actually ran into several scenarios
> before where I wished stash could do exactly this.
>
> On 11-06-20 9:36 PM, David Caldwell wrote:
>> On 6/20/11 5:38 PM, Jeff King wrote:
>>> Hmm. I think I would call this something like "--untracked", as to me
>>> the main function is saving those files, not cleaning them afterwards
>>> (the fact that they are cleaned is really just making the untracked-file
>>> handling in line with what we do for tracked files; we put the changes
>>> in the stash and remove them from the working tree).
>>
>> I see your point but I thought "--clean" was pretty descriptive of how
>> the working dir ended up afterward. Maybe "git stash --everything" (or
>> "--all")?
> I personally think "--untracked" (and -u) is more intuitive too, since it
> tells you what "git stash" is about to do. i.e. "git stash" is about to do
> the usual stash operation *and* also stash the "untracked" files.
Really?
$ git stash --untracked
sound like it stashes *only* untracked files. (That by itself may be a
feature that some people want; so far, I'm not among them.)
-- Hannes
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] stash: Add --clean option to stash and remove all untracked files
2011-06-21 6:28 ` Johannes Sixt
@ 2011-06-21 14:18 ` Jeff King
2011-06-21 16:11 ` Paul Ebermann
2011-06-21 17:16 ` Junio C Hamano
0 siblings, 2 replies; 12+ messages in thread
From: Jeff King @ 2011-06-21 14:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Andrew Wong, David Caldwell, git, Junio C Hamano
On Tue, Jun 21, 2011 at 08:28:31AM +0200, Johannes Sixt wrote:
> > I personally think "--untracked" (and -u) is more intuitive too, since it
> > tells you what "git stash" is about to do. i.e. "git stash" is about to do
> > the usual stash operation *and* also stash the "untracked" files.
>
> Really?
>
> $ git stash --untracked
>
> sound like it stashes *only* untracked files. (That by itself may be a
> feature that some people want; so far, I'm not among them.)
I would be happy with something that indicated "untracked files in
addition to the regular stash". I just think it should be about "add
these other files into the stash", not "end up in this directory state".
Something like "--untracked-too" fits that, but is horribly ugly. I also
think it makes sense to have some way of stashing everything, including
excluded files. That could just be "-x" in conjunction with whatever
this option is (which matches "git clean"), or it could be a separate
option name (like "--all" or "--ignored").
Things like "git stash --all" or "git stash --thorough" indicate that
you are stashing more, but it's hard to remember what the "more" is.
So I don't have any brilliant suggestions. Doing:
$ git stash --untracked-too --ignored-too
is fairly clear, but somehow strikes me as unnecessarily ugly and
verbose.
-Peff
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] stash: Add --clean option to stash and remove all untracked files
2011-06-21 14:18 ` Jeff King
@ 2011-06-21 16:11 ` Paul Ebermann
2011-06-21 21:23 ` Marc Branchaud
2011-06-22 7:47 ` Miles Bader
2011-06-21 17:16 ` Junio C Hamano
1 sibling, 2 replies; 12+ messages in thread
From: Paul Ebermann @ 2011-06-21 16:11 UTC (permalink / raw)
To: git; +Cc: Jeff King, Johannes Sixt, Andrew Wong, David Caldwell, Junio C Hamano
Jeff King schrieb:
> I would be happy with something that indicated "untracked files in
> addition to the regular stash". I just think it should be about "add
> these other files into the stash", not "end up in this directory state".
>
> Something like "--untracked-too" fits that, but is horribly ugly. I also
> think it makes sense to have some way of stashing everything, including
> excluded files. That could just be "-x" in conjunction with whatever
> this option is (which matches "git clean"), or it could be a separate
> option name (like "--all" or "--ignored").
>
> Things like "git stash --all" or "git stash --thorough" indicate that
> you are stashing more, but it's hard to remember what the "more" is.
>
> So I don't have any brilliant suggestions. Doing:
>
> $ git stash --untracked-too --ignored-too
>
> is fairly clear, but somehow strikes me as unnecessarily ugly and
> verbose.
I think `--also-untracked` sounds better. It is even longer, though.
There could also be `--only-untracked`, which would stack only the
untracked files (and let changes of tracked files there).
Paŭlo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] stash: Add --clean option to stash and remove all untracked files
2011-06-21 16:11 ` Paul Ebermann
@ 2011-06-21 21:23 ` Marc Branchaud
2011-06-22 7:47 ` Miles Bader
1 sibling, 0 replies; 12+ messages in thread
From: Marc Branchaud @ 2011-06-21 21:23 UTC (permalink / raw)
To: Paul Ebermann
Cc: git, Jeff King, Johannes Sixt, Andrew Wong, David Caldwell,
Junio C Hamano
On 11-06-21 12:11 PM, Paul Ebermann wrote:
>
> I think `--also-untracked` sounds better. It is even longer, though.
>
> There could also be `--only-untracked`, which would stack only the
> untracked files (and let changes of tracked files there).
Perhaps -uall to match git-status's -u[<mode>] option (and also the long
version thereof)?
M.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] stash: Add --clean option to stash and remove all untracked files
2011-06-21 16:11 ` Paul Ebermann
2011-06-21 21:23 ` Marc Branchaud
@ 2011-06-22 7:47 ` Miles Bader
2011-06-22 15:00 ` Jeff King
1 sibling, 1 reply; 12+ messages in thread
From: Miles Bader @ 2011-06-22 7:47 UTC (permalink / raw)
To: Paul Ebermann
Cc: git, Jeff King, Johannes Sixt, Andrew Wong, David Caldwell,
Junio C Hamano
Paul Ebermann <Paul.Ebermann@esperanto.de> writes:
>> $ git stash --untracked-too --ignored-too
>>
>> is fairly clear, but somehow strikes me as unnecessarily ugly and
>> verbose.
>
> I think `--also-untracked` sounds better. It is even longer, though.
"--include-untracked" sounds a bit smoother to my ears.
-Miles
--
Would you like fries with that?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] stash: Add --clean option to stash and remove all untracked files
2011-06-22 7:47 ` Miles Bader
@ 2011-06-22 15:00 ` Jeff King
0 siblings, 0 replies; 12+ messages in thread
From: Jeff King @ 2011-06-22 15:00 UTC (permalink / raw)
To: Miles Bader
Cc: Paul Ebermann, git, Johannes Sixt, Andrew Wong, David Caldwell,
Junio C Hamano
On Wed, Jun 22, 2011 at 04:47:03PM +0900, Miles Bader wrote:
> Paul Ebermann <Paul.Ebermann@esperanto.de> writes:
> >> $ git stash --untracked-too --ignored-too
> >>
> >> is fairly clear, but somehow strikes me as unnecessarily ugly and
> >> verbose.
> >
> > I think `--also-untracked` sounds better. It is even longer, though.
>
> "--include-untracked" sounds a bit smoother to my ears.
Me too. It's long, but it fits with other git commands.
-Peff
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] stash: Add --clean option to stash and remove all untracked files
2011-06-21 14:18 ` Jeff King
2011-06-21 16:11 ` Paul Ebermann
@ 2011-06-21 17:16 ` Junio C Hamano
1 sibling, 0 replies; 12+ messages in thread
From: Junio C Hamano @ 2011-06-21 17:16 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Andrew Wong, David Caldwell, git
Jeff King <peff@peff.net> writes:
> On Tue, Jun 21, 2011 at 08:28:31AM +0200, Johannes Sixt wrote:
>
>> > I personally think "--untracked" (and -u) is more intuitive too, since it
>> > tells you what "git stash" is about to do. i.e. "git stash" is about to do
>> > the usual stash operation *and* also stash the "untracked" files.
>>
>> Really?
>>
>> $ git stash --untracked
>>
>> sound like it stashes *only* untracked files. (That by itself may be a
>> feature that some people want; so far, I'm not among them.)
>
> I would be happy with something that indicated "untracked files in
> addition to the regular stash". I just think it should be about "add
> these other files into the stash", not "end up in this directory state".
>
> Something like "--untracked-too" fits that, but is horribly ugly.
This I think depends on how you view what stash does. If you concentrate
on the "saving" aspect too much, your naming would start from "untracked"
and end up to be that ugly thing. If you start from "what happens to the
working tree", on the other hand, --clean may not be such a bad name for
what it does.
But I think the previous point you raised about untracked-but-not-ignored
vs untracked-and-ignored is much more important. I do not think anybody
would want to put build products in stash and unstash them later, so in
that sense we can say we would only save the untracked-but-not-ignored in
the stash and remove them, but then "git stash --clean" (or whatever we
end up calling it) would still leave non-source material in the working
tree, which probably does not exactly the original motivation of wanting
to get a pristine source tree without having to trust the build procedure
(i.e. "make clean" may leave cruft behind).
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-06-22 15:00 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-22 5:49 [PATCH] stash: Add --clean option to stash and remove all untracked files David Caldwell
-- strict thread matches above, loose matches on Subject: below --
2011-06-20 23:36 David Caldwell
2011-06-21 0:38 ` Jeff King
2011-06-21 1:36 ` David Caldwell
2011-06-21 5:08 ` Andrew Wong
2011-06-21 6:28 ` Johannes Sixt
2011-06-21 14:18 ` Jeff King
2011-06-21 16:11 ` Paul Ebermann
2011-06-21 21:23 ` Marc Branchaud
2011-06-22 7:47 ` Miles Bader
2011-06-22 15:00 ` Jeff King
2011-06-21 17:16 ` Junio C Hamano
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.