[PATCH] git-stash: alias 'list' to 'ls' and 'clear' to 'rm'

[PATCH] git-stash: alias 'list' to 'ls' and 'clear' to 'rm'

[Tim Stoakes]

Signed-off-by: Tim Stoakes <tim@stoakes.net>
---
 Documentation/git-stash.txt |    2 ++
 git-stash.sh                |    4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index cd0dc1b..fc5866f 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -44,6 +44,7 @@ save [<message>]::
 	the description along with the stashed state.
 
 list::
+ls::
 
 	List the stashes that you currently have.  Each 'stash' is listed
 	with its name (e.g. `stash@\{0}` is the latest stash, `stash@\{1}` is
@@ -79,6 +80,7 @@ have conflicts (which are stored in the index, where you therefore can no
 longer apply the changes as they were originally).
 
 clear::
+rm::
 	Remove all the stashed states. Note that those states will then
 	be subject to pruning, and may be difficult or impossible to recover.
 
diff --git a/git-stash.sh b/git-stash.sh
index b00f888..8884950 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -198,7 +198,7 @@ apply_stash () {
 
 # Main command set
 case "$1" in
-list)
+list | ls)
 	shift
 	if test $# = 0
 	then
@@ -219,7 +219,7 @@ apply)
 	shift
 	apply_stash "$@"
 	;;
-clear)
+clear | rm)
 	shift
 	clear_stash "$@"
 	;;
-- 
1.5.4

Re: [PATCH] git-stash: alias 'list' to 'ls' and 'clear' to 'rm'

[Wincent Colaiuta]

El 5/2/2008, a las 11:38, Tim Stoakes escribió:

> clear::
> +rm::
> 	Remove all the stashed states. Note that those states will then
> 	be subject to pruning, and may be difficult or impossible to recover.

Isn't "rm" a bit misleading here? Seeing as the clear subcommand  
really does an "rm -rf".

Also, is there any other precedent in the command suite for  
abbreviating subcommand names in that way (ie. not just by shortening  
them, but by using alternative names based on filesystem commands)? It  
strikes me as a bit inconsistent.

Cheers,
Wincent

Re: [PATCH] git-stash: alias 'list' to 'ls' and 'clear' to 'rm'

[Tim Stoakes]

Wincent Colaiuta(win@wincent.com)@050208-12:06:
> El 5/2/2008, a las 11:38, Tim Stoakes escribi?:
>
>> clear::
>> +rm::
>> 	Remove all the stashed states. Note that those states will then
>> 	be subject to pruning, and may be difficult or impossible to recover.
>
> Isn't "rm" a bit misleading here? Seeing as the clear subcommand really 
> does an "rm -rf".

$ git stash clear foo
git stash clear with parameters is unimplemented

It appears that 'clear' is intended to behave like 'rm', however, it
isn't implemented yet.

> Also, is there any other precedent in the command suite for abbreviating 
> subcommand names in that way (ie. not just by shortening them, but by using 
> alternative names based on filesystem commands)? It strikes me as a bit 
> inconsistent.

For example 'git remote' uses 'rm', and there exists 'git rm', 'git
ls-files', 'git ls-remotes' etc. Granted, these are not abbreviations of
other (also available) longer term. The fact that some commands use
shell command names, and others use words, appears to be the
inconsistency to me. However, renaming 'git stash list' to 'git stash
ls' would break compatibility, so seemed too heavy to me.

Tim

-- 
Tim Stoakes

Re: [PATCH] git-stash: alias 'list' to 'ls' and 'clear' to 'rm'

[Wincent Colaiuta]

El 5/2/2008, a las 12:20, Tim Stoakes escribió:

> Wincent Colaiuta(win@wincent.com)@050208-12:06:
>> El 5/2/2008, a las 11:38, Tim Stoakes escribi?:
>>
>>> clear::
>>> +rm::
>>> 	Remove all the stashed states. Note that those states will then
>>> 	be subject to pruning, and may be difficult or impossible to  
>>> recover.
>>
>> Isn't "rm" a bit misleading here? Seeing as the clear subcommand  
>> really
>> does an "rm -rf".
>
> $ git stash clear foo
> git stash clear with parameters is unimplemented
>
> It appears that 'clear' is intended to behave like 'rm', however, it
> isn't implemented yet.

No, I don't think it was ever _intended_ to behave like rm. It does  
pretty much what the man page says, clears all stashed states and that  
was always its intention.

But lots of people have said that they'd like to be able to pop only  
to topmost stash off the stack, or delete a specific stash, and some  
have reported being caught by surprise and clearing all stashes when  
they only wanted to delete one of them. There were patch(es) to the  
mailing list a while back teaching "git reflog" to delete specific  
entries, and seeing as "git stash" is built on top of reflogs the idea  
was that if someone wants to implement a subcommand for deleting  
specific stashes (or a push/pop kind of thing) then the reflog stuff  
would enable that. I think the refog patch(es) was/were from Dscho. I  
can't remember who/if has followed up with push/pop/delete patches for  
"git stash".

Cheers,
Wincent

Re: [PATCH] git-stash: alias 'list' to 'ls' and 'clear' to 'rm'

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1871 bytes --]

Hi,

On Tue, 5 Feb 2008, Wincent Colaiuta wrote:

> El 5/2/2008, a las 12:20, Tim Stoakes escribió:
> 
> > Wincent Colaiuta(win@wincent.com)@050208-12:06:
> > > El 5/2/2008, a las 11:38, Tim Stoakes escribi?:
> > > 
> > > > clear::
> > > > +rm::
> > > > 	Remove all the stashed states. Note that those states will 
> > > >         then be subject to pruning, and may be difficult or 
> > > >         impossible to recover.
> > > 
> > > Isn't "rm" a bit misleading here? Seeing as the clear subcommand 
> > > really does an "rm -rf".
> > 
> > $ git stash clear foo
> > git stash clear with parameters is unimplemented
> > 
> > It appears that 'clear' is intended to behave like 'rm', however, it 
> > isn't implemented yet.
> 
> No, I don't think it was ever _intended_ to behave like rm. It does 
> pretty much what the man page says, clears all stashed states and that 
> was always its intention.
> 
> But lots of people have said that they'd like to be able to pop only to 
> topmost stash off the stack, or delete a specific stash, and some have 
> reported being caught by surprise and clearing all stashes when they 
> only wanted to delete one of them. There were patch(es) to the mailing 
> list a while back teaching "git reflog" to delete specific entries, and 
> seeing as "git stash" is built on top of reflogs the idea was that if 
> someone wants to implement a subcommand for deleting specific stashes 
> (or a push/pop kind of thing) then the reflog stuff would enable that. I 
> think the refog patch(es) was/were from Dscho. I can't remember who/if 
> has followed up with push/pop/delete patches for "git stash".

The followup was by Brandon (Cc'ed) to add "stash drop":

http://article.gmane.org/gmane.comp.version-control.git/69627/match=stash+drop

However, I did not like that "drop" should be introduced before "pop" 
(=apply&&drop).

Ciao,
Dscho

[PATCH WIP] git-stash: add new 'drop' subcommand

[Brandon Casey]

This allows a single stash entry to be deleted. It takes an
optional argument which is a stash reflog entry. If no
arguments are supplied, it drops the most recent stash entry.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---


Johannes Schindelin wrote:
> On Tue, 5 Feb 2008, Wincent Colaiuta wrote:
>> I can't remember who/if 
>> has followed up with push/pop/delete patches for "git stash".
>
> The followup was by Brandon (Cc'ed) to add "stash drop":

Here is the same patch rebased on top of next.

This doesn't work perfectly yet. One or both of refs/stash and
logs/refs/stash are not being updated correctly.

When the top-most stash is dropped, refs/stash is not updated to
contain the commit id of the new stash@{0}. A subsequent drop then
produces a warning like:

warning: Log .git/logs/refs/stash unexpectedly ended on Wed, 6 Feb 2008 10:00:20 -0600.

So this is still a work in progress.

Also missing is the ability to drop multiple stash entries at
one time. I think reflog delete will have to be modified to
accommodate this. What happens is that the deletions are performed
in a loop, and each deletion shifts the reflog entries so that they
don't necessarily point to the same thing.

    $ git stash list
    stash@{0} My fourth stash
    stash@{1} My third stash
    stash@{2} My second stash
    stash@{3} My first stash
    $ git reflog delete stash@{1} stash@{2}
    $ git stash list
    stash@{0} My fourth stash
    stash@{1} My second stash

"My third stash" and "My second stash" should have been deleted, but
"My first stash" was deleted instead.

-brandon


 Documentation/git-stash.txt |    7 ++++++-
 git-stash.sh                |   25 ++++++++++++++++++++++++-
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index cd0dc1b..f339a57 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -8,7 +8,7 @@ git-stash - Stash the changes in a dirty working directory away
 SYNOPSIS
 --------
 [verse]
-'git-stash' (list | show [<stash>] | apply [<stash>] | clear)
+'git-stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>])
 'git-stash' [save [<message>]]
 
 DESCRIPTION
@@ -82,6 +82,11 @@ clear::
 	Remove all the stashed states. Note that those states will then
 	be subject to pruning, and may be difficult or impossible to recover.
 
+drop [<stash>]::
+
+	Remove a single stashed state from the stash list. When no `<stash>`
+	is given, it removes the latest one. i.e. `stash@\{0}`
+
 
 DISCUSSION
 ----------
diff --git a/git-stash.sh b/git-stash.sh
index b00f888..d6d77fa 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 # Copyright (c) 2007, Nanako Shiraishi
 
-USAGE='[  | save | list | show | apply | clear | create ]'
+USAGE='[  | save | list | show | apply | clear | drop | create ]'
 
 SUBDIRECTORY_OK=Yes
 OPTIONS_SPEC=
@@ -196,6 +196,25 @@ apply_stash () {
 	fi
 }
 
+drop_stash () {
+	have_stash || die 'No stash entries to drop'
+
+	test $# = 0 && set -- "$ref_stash@{0}"
+
+	# Verify supplied argument looks like a stash entry
+	s=$(git rev-parse --revs-only --no-flags "$@") &&
+	git rev-parse --verify "$s:"   > /dev/null 2>&1 &&
+	git rev-parse --verify "$s^1:" > /dev/null 2>&1 &&
+	git rev-parse --verify "$s^2:" > /dev/null 2>&1 ||
+		die "$*: not a valid stashed state"
+
+	git reflog delete "$@" && echo "Dropped $* ($s)" ||
+		die "$*: Could not drop stash entry"
+
+	# clear_stash if we just dropped the last stash entry
+	git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
+}
+
 # Main command set
 case "$1" in
 list)
@@ -230,6 +249,10 @@ create)
 	fi
 	create_stash "$*" && echo "$w_commit"
 	;;
+drop)
+	shift
+	drop_stash "$@"
+	;;
 *)
 	if test $# -eq 0
 	then
-- 
1.5.4.1135.g75520

Re: [PATCH WIP] git-stash: add new 'drop' subcommand

[Paolo Bonzini]

> Also missing is the ability to drop multiple stash entries at
> one time. I think reflog delete will have to be modified to
> accommodate this. What happens is that the deletions are performed
> in a loop, and each deletion shifts the reflog entries so that they
> don't necessarily point to the same thing.

You just have to sort them backwards, either here or in git reflog.

> +drop)
> +	shift
> +	drop_stash "$@"

drop_stash $(echo "$@" | tr ' ' '\n' | sort -runt\{ -k2)

Paolo

Re: [PATCH WIP] git-stash: add new 'drop' subcommand

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

>> Also missing is the ability to drop multiple stash entries at
>> one time. I think reflog delete will have to be modified to
>> accommodate this. What happens is that the deletions are performed
>> in a loop, and each deletion shifts the reflog entries so that they
>> don't necessarily point to the same thing.
>
> You just have to sort them backwards, either here or in git reflog.
>
>> +drop)
>> +	shift
>> +	drop_stash "$@"
>
> drop_stash $(echo "$@" | tr ' ' '\n' | sort -runt\{ -k2)

Yes, but this makes me suspect that the parameter should be
simply "n m" instead of "stash@{n} stash@{m}".

Re: [PATCH WIP] git-stash: add new 'drop' subcommand

[Johannes Schindelin]

Hi,

On Wed, 6 Feb 2008, Brandon Casey wrote:

> This allows a single stash entry to be deleted. It takes an optional 
> argument which is a stash reflog entry. If no arguments are supplied, it 
> drops the most recent stash entry.

Just to repeat my opinion: "drop" is not useful.  I think 'git stash pop 
"$1"' = 'git stash apply "$1" && git stash drop "$1"' would be a sane 
interface.

And this means that a multiple drop would become uninteresting.

As for your reflog delete with multiple arguments... Right.  This needs a 
change in the callback data cmd_reflog_expire_cb, recno needs to become a 
pointer to an int, instead of an int.  Then, cmd_delete() has to allocate 
argc + 1 int values, setting the last to -1.  It has to shift the recno 
pointer in the loop to the respective next element of this allocated 
array.  The values need to be sorted after the loop in ascending order.  
Then, in a loop from the last to the second entry, the _difference_ 
array[i] - array[i-1] has to be stored in array[i].  Also, recno has to be 
reset to the first element in the array.  Then, expire_reflog_ent() has to 
be changed to check "recno && *recno >= 0", and if "--*(cb->cmd->recno) == 
0", it not only has to prune, but before that increment cb->cmd->recno, so 
it points to the next element of the array.

Also, I think that "reflog delete" should probably just realise when it 
deleted the last element, and update the ref with the new last element (or 
delete it if none is left).

Ciao,
Dscho