threads / patch / 11892

patchgit-stash: alias 'list' to 'ls' and 'clear' to 'rm'

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

## tl;dr

9 messages between Feb 5, 2008 and Feb 6, 2008. Diffs are folded; open one to read it.

replies: 8people: 6as markdown or json

Tim Stoakes· Feb 5, 2008, 10:38 UTC · lore
Signed-off-by: Tim Stoakes <tim@stoakes.net>
---
 Documentation/git-stash.txt |    2 ++
 git-stash.sh                |    4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)
Show changes to 2 files +4 −2

Documentation/git-stash.txt, git-stash.sh

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
Wincent Colaiuta· Feb 5, 2008, 11:06 UTC · re: Tim Stoakes · lore

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

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

Tim Stoakes· Feb 5, 2008, 11:20 UTC · re: Wincent Colaiuta · lore

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

Wincent Colaiuta(win@wincent.com)@050208-12:06:
Show 9 quoted lines
> 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
Wincent Colaiuta· Feb 5, 2008, 12:12 UTC · re: Tim Stoakes · lore

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

El 5/2/2008, a las 12:20, Tim Stoakes escribió:
Show 18 quoted lines
> 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

Johannes Schindelin· Feb 5, 2008, 14:03 UTC · re: Wincent Colaiuta · lore

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

Hi,
On Tue, 5 Feb 2008, Wincent Colaiuta wrote:
Show 34 quoted lines
> 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

Brandon Casey· Feb 6, 2008, 16:19 UTC · re: Johannes Schindelin · lore

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

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:
Show 5 quoted lines
> 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(-)
Show changes to 2 files +30 −2

Documentation/git-stash.txt, git-stash.sh

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
Paolo Bonzini· Feb 6, 2008, 17:11 UTC · re: Brandon Casey · lore

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

Show 5 quoted lines
> 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
Junio C Hamano· Feb 6, 2008, 19:44 UTC · re: Paolo Bonzini · lore

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

Paolo Bonzini <bonzini@gnu.org> writes:
Show 13 quoted lines
>> 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}".

Johannes Schindelin· Feb 6, 2008, 23:53 UTC · re: Brandon Casey · lore

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

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

← back to recent threads