git-stash: RFC: Adopt the default behavior to other commands

git-stash: RFC: Adopt the default behavior to other commands

[Sebastian Harl]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

Hi,

By default, git-stash (when called without any other arguments) creates a new
stash. This is quite different to the behavior of most other Git commands
(e.g. git-tag, git-branch, etc. do "list" by default). In order to improve
consistency git-stash should imho adopt this as well.

The creation of a new stash should not do any harm. However, I think that
consistency is more important (iirc this has been mentioned in the current
survey a couple of times) and doing "list" is (in general) the best default.

Comments?

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: git-stash: RFC: Adopt the default behavior to other commands

[Benoit Sigoure]

On Dec 17, 2007, at 12:03 PM, Sebastian Harl wrote:

> Hi,
>
> By default, git-stash (when called without any other arguments)  
> creates a new
> stash. This is quite different to the behavior of most other Git  
> commands
> (e.g. git-tag, git-branch, etc. do "list" by default). In order to  
> improve
> consistency git-stash should imho adopt this as well.
>
> The creation of a new stash should not do any harm. However, I  
> think that
> consistency is more important (iirc this has been mentioned in the  
> current
> survey a couple of times) and doing "list" is (in general) the best  
> default.


Hi Sebastian,
this topic has been brought up the ML several times already, and  
there seems to be some sort of consensus on the misbehavior of git  
stash and what the default should be (listing the stashes seems like  
a decent default action).  The current behavior of git stash is very  
dangerous as the following frequently happens to new comers:
   $ git stash
   $ <hack on something else>
   $ git commit
   $ git stash apply
   $ git stash clean # Oops, typo, I just stashed my changes again
   $ git stash clear # Oops, I just lost my changed

Hopefully, Git gives you means to recover from this sort of error,  
but most of the time new comers don't know them and just assume they  
lost their work.

Whenever I use git stash, it gives me chills, because I know I can  
easily screw things up (even though now I know how to recover from  
this sort of "user error").

Cheers,

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

Re: git-stash: RFC: Adopt the default behavior to other commands

[Junio C Hamano]

Benoit Sigoure <tsuna@lrde.epita.fr> writes:

> ...  The current behavior of git stash is very
> dangerous as the following frequently happens to new comers:
>   $ git stash
>   $ <hack on something else>
>   $ git commit
>   $ git stash apply
>   $ git stash clean # Oops, typo, I just stashed my changes again
>   $ git stash clear # Oops, I just lost my changed

This is a plain FUD, isn't it?  The first Oops should not happen these
days.

Re: git-stash: RFC: Adopt the default behavior to other commands

[Benoit Sigoure]

On Dec 18, 2007, at 12:00 AM, Junio C Hamano wrote:

> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>
>> ...  The current behavior of git stash is very
>> dangerous as the following frequently happens to new comers:
>>   $ git stash
>>   $ <hack on something else>
>>   $ git commit
>>   $ git stash apply
>>   $ git stash clean # Oops, typo, I just stashed my changes again
>>   $ git stash clear # Oops, I just lost my changed
>
> This is a plain FUD, isn't it?  The first Oops should not happen these
> days.


*git pull in git*
*reads Documentation/RelNotes-1.5.4.txt*

Blah.  I didn't know follow the development over the past 3 weeks  
well enough, sorry for the noise.  I'm glad that this was improved.

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

Re: git-stash: RFC: Adopt the default behavior to other commands

[Junio C Hamano]

Benoit Sigoure <tsuna@lrde.epita.fr> writes:

> On Dec 18, 2007, at 12:00 AM, Junio C Hamano wrote:
>
>> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>>
>>> ...  The current behavior of git stash is very
>>> dangerous ...
> ...
>> This is a plain FUD, isn't it?  The first Oops should not happen these
>> days.
>
> *git pull in git*
> *reads Documentation/RelNotes-1.5.4.txt*
>
> Blah.  I didn't know follow the development over the past 3 weeks well
> enough, sorry for the noise.  I'm glad that this was improved.

But the original point by Sebastian hasn't been answered.  He wanted to
make the command list the stash without arguments.

This was discussed already in the early days of stash and there indeed
was a suggestion to do so (I think I sided with that), but the users did
not want it.  IIRC, the argument went like: "when I say 'stash', that is
because I want a quick and immediate way to stash, and I do not want a
list.  If I do not have to have a quick way, I would create a temporary
commit on the current branch, or switch to a temporary branch and commit
there."

Re: git-stash: RFC: Adopt the default behavior to other commands

[Sebastian Harl]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

Hi,

On Mon, Dec 17, 2007 at 04:31:12PM -0800, Junio C Hamano wrote:
> But the original point by Sebastian hasn't been answered.  He wanted to
> make the command list the stash without arguments.
> 
> This was discussed already in the early days of stash and there indeed
> was a suggestion to do so (I think I sided with that), but the users did
> not want it.  IIRC, the argument went like: "when I say 'stash', that is
> because I want a quick and immediate way to stash, and I do not want a
> list.  If I do not have to have a quick way, I would create a temporary
> commit on the current branch, or switch to a temporary branch and commit
> there."

Well, "git stash save" is just five characters more - I really don't see why
this would be less comfortable (and for the really lazy people there are still
aliases...). On the other hand (if "list" is the default), we'd get a more
consistent interface which imho is imho more important than typing five
characters less.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: git-stash: RFC: Adopt the default behavior to other commands

[Johannes Schindelin]

Hi,

On Tue, 18 Dec 2007, Sebastian Harl wrote:

> On Mon, Dec 17, 2007 at 04:31:12PM -0800, Junio C Hamano wrote:
> > But the original point by Sebastian hasn't been answered.  He wanted 
> > to make the command list the stash without arguments.
> > 
> > This was discussed already in the early days of stash and there indeed 
> > was a suggestion to do so (I think I sided with that), but the users 
> > did not want it.  IIRC, the argument went like: "when I say 'stash', 
> > that is because I want a quick and immediate way to stash, and I do 
> > not want a list.  If I do not have to have a quick way, I would create 
> > a temporary commit on the current branch, or switch to a temporary 
> > branch and commit there."
> 
> Well, "git stash save" is just five characters more - I really don't see 
> why this would be less comfortable (and for the really lazy people there 
> are still aliases...). On the other hand (if "list" is the default), 
> we'd get a more consistent interface which imho is imho more important 
> than typing five characters less.

It's more about what you're used to.  I had an alias named 'stash' long 
before it became a git command.  And now guess how _annoying_ it would be 
to type "git stash<Return><Curse out loud at my mouse>git stash 
save<Return>".

As you see, it is more than five characters more.

Ciao,
Dscho

Re: git-stash: RFC: Adopt the default behavior to other commands

[Andreas Ericsson]

Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 18 Dec 2007, Sebastian Harl wrote:
> 
>> On Mon, Dec 17, 2007 at 04:31:12PM -0800, Junio C Hamano wrote:
>>> But the original point by Sebastian hasn't been answered.  He wanted 
>>> to make the command list the stash without arguments.
>>>
>>> This was discussed already in the early days of stash and there indeed 
>>> was a suggestion to do so (I think I sided with that), but the users 
>>> did not want it.  IIRC, the argument went like: "when I say 'stash', 
>>> that is because I want a quick and immediate way to stash, and I do 
>>> not want a list.  If I do not have to have a quick way, I would create 
>>> a temporary commit on the current branch, or switch to a temporary 
>>> branch and commit there."
>> Well, "git stash save" is just five characters more - I really don't see 
>> why this would be less comfortable (and for the really lazy people there 
>> are still aliases...). On the other hand (if "list" is the default), 
>> we'd get a more consistent interface which imho is imho more important 
>> than typing five characters less.
> 
> It's more about what you're used to.  I had an alias named 'stash' long 
> before it became a git command.  And now guess how _annoying_ it would be 
> to type "git stash<Return><Curse out loud at my mouse>git stash 
> save<Return>".
> 

Not nearly as annoying as losing work because of it, and you obviously
*know* what to do when you're done cursing, while clueless-newbie-X just
hops away and uses subversion.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git-stash: RFC: Adopt the default behavior to other commands

[Johannes Schindelin]

Hi,

On Tue, 18 Dec 2007, Andreas Ericsson wrote:

> Johannes Schindelin wrote:
> 
> > On Tue, 18 Dec 2007, Sebastian Harl wrote:
> > 
> > > On Mon, Dec 17, 2007 at 04:31:12PM -0800, Junio C Hamano wrote:
> > > > But the original point by Sebastian hasn't been answered.  He 
> > > > wanted to make the command list the stash without arguments.
> > > > 
> > > > This was discussed already in the early days of stash and there 
> > > > indeed was a suggestion to do so (I think I sided with that), but 
> > > > the users did not want it.  IIRC, the argument went like: "when I 
> > > > say 'stash', that is because I want a quick and immediate way to 
> > > > stash, and I do not want a list.  If I do not have to have a quick 
> > > > way, I would create a temporary commit on the current branch, or 
> > > > switch to a temporary branch and commit there."
> > > Well, "git stash save" is just five characters more - I really don't 
> > > see why this would be less comfortable (and for the really lazy 
> > > people there are still aliases...). On the other hand (if "list" is 
> > > the default), we'd get a more consistent interface which imho is 
> > > imho more important than typing five characters less.
> > 
> > It's more about what you're used to.  I had an alias named 'stash' 
> > long before it became a git command.  And now guess how _annoying_ it 
> > would be to type "git stash<Return><Curse out loud at my mouse>git 
> > stash save<Return>".
> 
> Not nearly as annoying as losing work because of it, and you obviously 
> *know* what to do when you're done cursing, while clueless-newbie-X just 
> hops away and uses subversion.

Really?  Clueless-newbie-X certainly knows how to apply the stash, 
otherwise she would not have used the command, right?

In the alternative, you could just scrap all those default actions, 
showing synopses instead.  For all commands, including "git commit", "git 
log", "git fetch", etc.

See?

Ciao,
Dscho

Re: git-stash: RFC: Adopt the default behavior to other commands

[Andreas Ericsson]

Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 18 Dec 2007, Andreas Ericsson wrote:
> 
>> Johannes Schindelin wrote:
>>
>>> On Tue, 18 Dec 2007, Sebastian Harl wrote:
>>>
>>>> On Mon, Dec 17, 2007 at 04:31:12PM -0800, Junio C Hamano wrote:
>>>>> But the original point by Sebastian hasn't been answered.  He 
>>>>> wanted to make the command list the stash without arguments.
>>>>>
>>>>> This was discussed already in the early days of stash and there 
>>>>> indeed was a suggestion to do so (I think I sided with that), but 
>>>>> the users did not want it.  IIRC, the argument went like: "when I 
>>>>> say 'stash', that is because I want a quick and immediate way to 
>>>>> stash, and I do not want a list.  If I do not have to have a quick 
>>>>> way, I would create a temporary commit on the current branch, or 
>>>>> switch to a temporary branch and commit there."
>>>> Well, "git stash save" is just five characters more - I really don't 
>>>> see why this would be less comfortable (and for the really lazy 
>>>> people there are still aliases...). On the other hand (if "list" is 
>>>> the default), we'd get a more consistent interface which imho is 
>>>> imho more important than typing five characters less.
>>> It's more about what you're used to.  I had an alias named 'stash' 
>>> long before it became a git command.  And now guess how _annoying_ it 
>>> would be to type "git stash<Return><Curse out loud at my mouse>git 
>>> stash save<Return>".
>> Not nearly as annoying as losing work because of it, and you obviously 
>> *know* what to do when you're done cursing, while clueless-newbie-X just 
>> hops away and uses subversion.
> 
> Really?  Clueless-newbie-X certainly knows how to apply the stash, 
> otherwise she would not have used the command, right?
> 

Far too many times I've seen people expect help output if the command
they're running is even remotely dangerous, so they go ahead and run
it without arguments to see what it does.


> In the alternative, you could just scrap all those default actions, 
> showing synopses instead.  For all commands, including "git commit", "git 
> log", "git fetch", etc.
> 

Like we do for the git wrapper, you mean? Yes, that would be one solution,
although not a very good one for all commands.

It's probably not a bad idea for commands where the primary use is
something else than producing visual output though, such as tag or branch,
but those handle creation/deletion of stuff, so the default action for them
is to list stuff of the kind they operate on. I fail to see why stash should
be any different.

> See?
> 

Not really, no. What was your point?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git-stash: RFC: Adopt the default behavior to other commands

[Johannes Schindelin]

Hi,

On Tue, 18 Dec 2007, Andreas Ericsson wrote:

> Johannes Schindelin wrote:
>
> > In the alternative, you could just scrap all those default actions, 
> > showing synopses instead.  For all commands, including "git commit", 
> > "git log", "git fetch", etc.
> 
> Like we do for the git wrapper, you mean? Yes, that would be one 
> solution, although not a very good one for all commands.

Exactly.  Not a good one.

> It's probably not a bad idea for commands where the primary use is 
> something else than producing visual output though, such as tag or 
> branch, but those handle creation/deletion of stuff, so the default 
> action for them is to list stuff of the kind they operate on. I fail to 
> see why stash should be any different.

I also fail to see why stash should be any different.  And that's why I 
expect it to have a default operation, which is -- you guessed it -- 
"stash the changes!"

If I am not sure what I am about to do, there is -- wonder of wonders -- 
the "-h" option!  And indeed:

	$ git stash -h
	Usage: /home/gitte/bin/git-stash [  | save | list | show | apply | 
		clear | create ]

So what exactly was your point again?

Ciao,
Dscho

Re: git-stash: RFC: Adopt the default behavior to other commands

[Andreas Ericsson]

Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 18 Dec 2007, Andreas Ericsson wrote:
> 
>> Johannes Schindelin wrote:
>>
>>> In the alternative, you could just scrap all those default actions, 
>>> showing synopses instead.  For all commands, including "git commit", 
>>> "git log", "git fetch", etc.
>> Like we do for the git wrapper, you mean? Yes, that would be one 
>> solution, although not a very good one for all commands.
> 
> Exactly.  Not a good one.
> 
>> It's probably not a bad idea for commands where the primary use is 
>> something else than producing visual output though, such as tag or 
>> branch, but those handle creation/deletion of stuff, so the default 
>> action for them is to list stuff of the kind they operate on. I fail to 
>> see why stash should be any different.
> 
> I also fail to see why stash should be any different.  And that's why I 
> expect it to have a default operation, which is -- you guessed it -- 
> "stash the changes!"
> 

Actually, I guessed "list the stashes".

> If I am not sure what I am about to do, there is -- wonder of wonders -- 
> the "-h" option!  And indeed:
> 
> 	$ git stash -h
> 	Usage: /home/gitte/bin/git-stash [  | save | list | show | apply | 
> 		clear | create ]
> 
> So what exactly was your point again?
> 

My point is that it would be nice if all git commands that actually
manipulate objects (create/delete/modify) had a safe default, and
that experienced users such as yourself could endure the insufferable
agony of retraining your fingers to type five more chars so that
people won't have to get bitten by surprises.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git-stash: RFC: Adopt the default behavior to other commands

[Jakub Narebski]

Andreas Ericsson <ae@op5.se> writes:
> Johannes Schindelin wrote:
>> On Tue, 18 Dec 2007, Andreas Ericsson wrote:
>>> Johannes Schindelin wrote:
>>>
>>>> In the alternative, you could just scrap all those default
>>>> actions, showing synopses instead.  For all commands, including
>>>> "git commit", "git log", "git fetch", etc.
>>>
>>> Like we do for the git wrapper, you mean? Yes, that would be one
>>> solution, although not a very good one for all commands.
>>
>> Exactly.  Not a good one.
>>
>>> It's probably not a bad idea for commands where the primary use is
>>> something else than producing visual output though, such as tag or
>>> branch, but those handle creation/deletion of stuff, so the default
>>> action for them is to list stuff of the kind they operate on. I
>>> fail to see why stash should be any different.
>>
>> I also fail to see why stash should be any different.  And that's why
>> I expect it to have a default operation, which is -- you guessed it -- 
>> "stash the changes!"
> 
> Actually, I guessed "list the stashes".
> 
>> If I am not sure what I am about to do, there is -- wonder of wonders -- 
>> the "-h" option!  And indeed:
>> 	$ git stash -h
>> 	Usage: /home/gitte/bin/git-stash [  | save | list | show |
>> apply | 		clear | create ]
>> So what exactly was your point again?
>>
> 
> My point is that it would be nice if all git commands that actually
> manipulate objects (create/delete/modify) had a safe default, and
> that experienced users such as yourself could endure the insufferable
> agony of retraining your fingers to type five more chars so that
> people won't have to get bitten by surprises.

Also for "git commit"?

In my opinion _basic_ usage of git-stash is simply using it with
one stash only: "git stash" / "git unstash" (i.e. "git stash apply";
by the way this is one (beside "git view") use case for builtin
predefined aliases).  Using it with multiple stashes (only then
"git stash list" is needed) is advanced usage; and for advanced
usage longer form is preferred, I think.

"git branch", "git log" and "git remote" are horse of differenc color
because the _cannot_ function without name of branch/tag/remote given,
so hey provide "list" when no name was given.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: git-stash: RFC: Adopt the default behavior to other commands

[Andreas Ericsson]

Jakub Narebski wrote:
> Andreas Ericsson <ae@op5.se> writes:
>> Johannes Schindelin wrote:
>>> On Tue, 18 Dec 2007, Andreas Ericsson wrote:
>>>> Johannes Schindelin wrote:
>>>>
>>>>> In the alternative, you could just scrap all those default
>>>>> actions, showing synopses instead.  For all commands, including
>>>>> "git commit", "git log", "git fetch", etc.
>>>> Like we do for the git wrapper, you mean? Yes, that would be one
>>>> solution, although not a very good one for all commands.
>>> Exactly.  Not a good one.
>>>
>>>> It's probably not a bad idea for commands where the primary use is
>>>> something else than producing visual output though, such as tag or
>>>> branch, but those handle creation/deletion of stuff, so the default
>>>> action for them is to list stuff of the kind they operate on. I
>>>> fail to see why stash should be any different.
>>> I also fail to see why stash should be any different.  And that's why
>>> I expect it to have a default operation, which is -- you guessed it -- 
>>> "stash the changes!"
>> Actually, I guessed "list the stashes".
>>
>>> If I am not sure what I am about to do, there is -- wonder of wonders -- 
>>> the "-h" option!  And indeed:
>>> 	$ git stash -h
>>> 	Usage: /home/gitte/bin/git-stash [  | save | list | show |
>>> apply | 		clear | create ]
>>> So what exactly was your point again?
>>>
>> My point is that it would be nice if all git commands that actually
>> manipulate objects (create/delete/modify) had a safe default, and
>> that experienced users such as yourself could endure the insufferable
>> agony of retraining your fingers to type five more chars so that
>> people won't have to get bitten by surprises.
> 
> Also for "git commit"?
> 

git commit has a very safe default; It runs "git status" and exits.

> In my opinion _basic_ usage of git-stash is simply using it with
> one stash only: "git stash" / "git unstash" (i.e. "git stash apply";
> by the way this is one (beside "git view") use case for builtin
> predefined aliases).  Using it with multiple stashes (only then
> "git stash list" is needed) is advanced usage; and for advanced
> usage longer form is preferred, I think.
> 

Perhaps. I'll stop quibbling about it. I don't care very deeply
about it anyway.

> "git branch", "git log" and "git remote" are horse of differenc color
> because the _cannot_ function without name of branch/tag/remote given,
> so hey provide "list" when no name was given.
> 

git stash takes a name too. It's optional though, and has caused any
number of source lines to be rewritten by grumbling authors who just
started to like git a little less because of it (yes, I know that has
been fixed, but it makes me look twice when discussing defaults for
git stash).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git-stash: RFC: Adopt the default behavior to other commands

[Johannes Schindelin]

Hi,

On Tue, 18 Dec 2007, Andreas Ericsson wrote:

> Jakub Narebski wrote:
>
> > Andreas Ericsson <ae@op5.se> writes:
> >
> > > My point is that it would be nice if all git commands that actually 
> > > manipulate objects (create/delete/modify) had a safe default, and 
> > > that experienced users such as yourself could endure the 
> > > insufferable agony of retraining your fingers to type five more 
> > > chars so that people won't have to get bitten by surprises.
> > 
> > Also for "git commit"?
> 
> git commit has a very safe default; It runs "git status" and exits.

Not in my universe.  It starts an editor, and then commits what I staged.

> > In my opinion _basic_ usage of git-stash is simply using it with one 
> > stash only: "git stash" / "git unstash" (i.e. "git stash apply"; by 
> > the way this is one (beside "git view") use case for builtin 
> > predefined aliases).  Using it with multiple stashes (only then "git 
> > stash list" is needed) is advanced usage; and for advanced usage 
> > longer form is preferred, I think.
> > 
> 
> Perhaps. I'll stop quibbling about it. I don't care very deeply about it 
> anyway.

Ah.  That explains why you made a case against the default operation ;-)

Ciao,
Dscho

Re: git-stash: RFC: Adopt the default behavior to other commands

[Sergei Organov]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 18 Dec 2007, Andreas Ericsson wrote:
>
>> Jakub Narebski wrote:
>>
>> > Andreas Ericsson <ae@op5.se> writes:
>> >
>> > > My point is that it would be nice if all git commands that actually 
>> > > manipulate objects (create/delete/modify) had a safe default, and 
>> > > that experienced users such as yourself could endure the 
>> > > insufferable agony of retraining your fingers to type five more 
>> > > chars so that people won't have to get bitten by surprises.
>> > 
>> > Also for "git commit"?
>> 
>> git commit has a very safe default; It runs "git status" and exits.
>
> Not in my universe.  It starts an editor, and then commits what I
> staged.

... allowing you to abort the operation by means of providing empty
commit message. On the other hand, "git stash" has immediate effect, so
it's somewhat more dangerous. Just to be picky, anyway.

-- 
Sergei.

Re: git-stash: RFC: Adopt the default behavior to other commands

[Johannes Schindelin]

Hi,

On Tue, 18 Dec 2007, Sergei Organov wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 18 Dec 2007, Andreas Ericsson wrote:
> >
> >> Jakub Narebski wrote:
> >>
> >> > Andreas Ericsson <ae@op5.se> writes:
> >> >
> >> > > My point is that it would be nice if all git commands that 
> >> > > actually manipulate objects (create/delete/modify) had a safe 
> >> > > default, and that experienced users such as yourself could endure 
> >> > > the insufferable agony of retraining your fingers to type five 
> >> > > more chars so that people won't have to get bitten by surprises.
> >> > 
> >> > Also for "git commit"?
> >> 
> >> git commit has a very safe default; It runs "git status" and exits.
> >
> > Not in my universe.  It starts an editor, and then commits what I 
> > staged.
> 
> ... allowing you to abort the operation by means of providing empty 
> commit message. On the other hand, "git stash" has immediate effect, so 
> it's somewhat more dangerous. Just to be picky, anyway.

Sorry, I have no time for this kind of discussions.

Ciao,
Dscho

Re: git-stash: RFC: Adopt the default behavior to other commands

[Martin Langhoff]

On Dec 19, 2007 7:03 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Sorry, I have no time for this kind of discussions.

Johannes,

the way you normally "say" that is by not replying. Please help keep
things civil.

cheers,


martin

Re: git-stash: RFC: Adopt the default behavior to other commands

[Wincent Colaiuta]

El 18/12/2007, a las 15:22, Andreas Ericsson escribió:

> Johannes Schindelin wrote:
>> Hi,
>> On Tue, 18 Dec 2007, Sebastian Harl wrote:
>>> On Mon, Dec 17, 2007 at 04:31:12PM -0800, Junio C Hamano wrote:
>>>> But the original point by Sebastian hasn't been answered.  He  
>>>> wanted to make the command list the stash without arguments.
>>>>
>>>> This was discussed already in the early days of stash and there  
>>>> indeed was a suggestion to do so (I think I sided with that), but  
>>>> the users did not want it.  IIRC, the argument went like: "when I  
>>>> say 'stash', that is because I want a quick and immediate way to  
>>>> stash, and I do not want a list.  If I do not have to have a  
>>>> quick way, I would create a temporary commit on the current  
>>>> branch, or switch to a temporary branch and commit there."
>>> Well, "git stash save" is just five characters more - I really  
>>> don't see why this would be less comfortable (and for the really  
>>> lazy people there are still aliases...). On the other hand (if  
>>> "list" is the default), we'd get a more consistent interface which  
>>> imho is imho more important than typing five characters less.
>> It's more about what you're used to.  I had an alias named 'stash'  
>> long before it became a git command.  And now guess how _annoying_  
>> it would be to type "git stash<Return><Curse out loud at my  
>> mouse>git stash save<Return>".
>
> Not nearly as annoying as losing work because of it, and you obviously
> *know* what to do when you're done cursing, while clueless-newbie-X  
> just
> hops away and uses subversion.

There's not really any peril of losing work here, seeing as this  
should be a lossless round trip:

git stash
# oops! didn't mean to save
git stash apply

We could help clueless-newbie-X here by augmenting the save output:

   Saved "WIP on master: 8ed8a26... s"
   HEAD is now at 8ed8a26... s

As follows (or similar):

   Saved working directory and index state "WIP on master: 8ed8a26... s"
   (To restore them type "git stash apply")
   HEAD is now at 8ed8a26... s

ie. we explicitly tell them what was saved (their working directory  
and index state), and also how to get it back immediately if that's  
not what they meant to do. Something like this (no doubt will be  
whitespace-mangled because I'm pasting this into my email client, but  
it's just to demo the idea):

diff --git a/git-stash.sh b/git-stash.sh
index f16fd9c..a2f3723 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -99,7 +99,8 @@ save_stash () {

         git update-ref -m "$stash_msg" $ref_stash $w_commit ||
                 die "Cannot save the current status"
-       printf >&2 'Saved "%s"\n' "$stash_msg"
+       printf >&2 'Saved working directory and index state "%s"\n'  
"$stash_msg"
+       echo >&2 '(To restore them type "git stash apply")'
  }

  have_stash () {

Cheers,
Wincent

Re: git-stash: RFC: Adopt the default behavior to other commands

[Jörg Sommer]

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

Hi,

Junio C Hamano schrieb am Mon 17. Dec, 16:31 (-0800):
> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> 
> >> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> >>
> >>> ...  The current behavior of git stash is very
> >>> dangerous ...
> > ...
> >> This is a plain FUD, isn't it?  The first Oops should not happen these
> >> days.
> 
> But the original point by Sebastian hasn't been answered.  He wanted to
> make the command list the stash without arguments.
> 
> This was discussed already in the early days of stash and there indeed
> was a suggestion to do so (I think I sided with that), but the users did
> not want it.  IIRC, the argument went like: "when I say 'stash', that is
> because I want a quick and immediate way to stash, and I do not want a
> list.  If I do not have to have a quick way, I would create a temporary
> commit on the current branch, or switch to a temporary branch and commit
> there."

When it should go quick why don't use an alias. git stash can print the
list and everyone who wants a quick stash can create an alias for this.

I vote for stash print the list, because I dropped in the pitfall.

Bye, Jörg.
-- 
Die beste Tarnung ist die Wahrheit. Die glaubt einem keiner!
                      (Max Frisch: ‚Biedermann und die Brandstifter‘)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: git-stash: RFC: Adopt the default behavior to other commands

[Johannes Schindelin]

Hi,

[please do not cull me from the Cc list, should you reply to this]

On Tue, 18 Dec 2007, J?rg Sommer wrote:

> Junio C Hamano schrieb am Mon 17. Dec, 16:31 (-0800):
> > Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> > 
> > >> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> > >>
> > >>> ...  The current behavior of git stash is very
> > >>> dangerous ...
> > > ...
> > >> This is a plain FUD, isn't it?  The first Oops should not happen 
> > >> these days.
> > 
> > But the original point by Sebastian hasn't been answered.  He wanted 
> > to make the command list the stash without arguments.
> > 
> > This was discussed already in the early days of stash and there indeed 
> > was a suggestion to do so (I think I sided with that), but the users 
> > did not want it.  IIRC, the argument went like: "when I say 'stash', 
> > that is because I want a quick and immediate way to stash, and I do 
> > not want a list.  If I do not have to have a quick way, I would create 
> > a temporary commit on the current branch, or switch to a temporary 
> > branch and commit there."
> 
> When it should go quick why don't use an alias. git stash can print the 
> list and everyone who wants a quick stash can create an alias for this.
> 
> I vote for stash print the list, because I dropped in the pitfall.

And in a fresh clone, this list is empty, showing nothing at all.  Leading 
the other half of the users to believe that the stash succeeded.

If stashing as the default operation of stash is ill-advised, showing the 
list is even more so.

Ciao,
Dscho

Re: git-stash: RFC: Adopt the default behavior to other commands

[Junio C Hamano]

Jörg Sommer <joerg@alea.gnuu.de> writes:

> When it should go quick why don't use an alias. git stash can print the
> list and everyone who wants a quick stash can create an alias for this.

You are taking this completely backwards.  The stash mechanism is all
about creating a quickie temporary pair of commits.  Anybody who wants
otherwise can use alias or choose not to use stash at all.

Re: git-stash: RFC: Adopt the default behavior to other commands

[しらいしななこ]

Quoting Junio C Hamano <gitster@pobox.com>:
> Jörg Sommer <joerg@alea.gnuu.de> writes:
>
>> When it should go quick why don't use an alias. git stash can print the
>> list and everyone who wants a quick stash can create an alias for this.
>
> You are taking this completely backwards.  The stash mechanism is all
> about creating a quickie temporary pair of commits.  Anybody who wants
> otherwise can use alias or choose not to use stash at all.

You are of course right.  That was the reason I made 
git-stash command behave that way in the first place.

But I see that some people on the list find this behavior 
dangerous and I can understand their fears.  Until one 
learns that one can go back to the state before running 
git-stash by running "git-stash apply" soon after that, 
it appears to one that the work is lost.

How about making this behavior configurable?

-- 8< --
[PATCH] Make "git stash" configurable

"git stash" without argument originally created an unnamed 
stash, but some people felt this can be confusing to new 
users.  This introduces config variable stash.quick to 
control this behavior.

The variable can take one of three values: true, false, ask.

When set to "true", the command allows to create a quick 
stash without any user interaction.  When set to "false", 
the command shows the list of stash instead.  When set to 
"ask", the command asks the user.

For the first time users, when the variable is not set, 
the command helps the user to set it interactively.

Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>

---

 git-stash.sh |   72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 70 insertions(+), 2 deletions(-)

diff --git a/git-stash.sh b/git-stash.sh
index f16fd9c..4bb7134 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -192,6 +192,69 @@ apply_stash () {
 	fi
 }
 
+allow_quick_stash () {
+	
+	quick=$(git config stash.quick)
+	if test $? != 0
+	then
+		if ! test -t 0 || ! test -t 1
+		then
+			return 0
+		fi
+	
+		echo '
+*** First time users ***
+
+"git stash" can create an unnamed stash entry without user interaction.
+This is a quick way to save away your work in progress.  Some people
+find this behaviour confusing or dangerous to new users.  You can
+configure the command to list the existing stash entries instead.'
+		
+		while :
+		do
+			echo '
+Do you want the command without argument to always...
+
+1. Ask for confirmation
+2. Create an unnamed stash
+3. List existing stash entries
+'
+			printf 'Which one? [1/2/3] '
+			read reply
+			quick=
+			case "$reply" in
+			1|A*)	quick=ask ;;
+			2|C*)	quick=true ;;
+			3|L*)	quick=false ;;
+			*)	continue ;;
+			esac
+			break
+		done
+		git config stash.quick $quick
+		echo '
+You can reconfigure this by editing your $HOME/.gitconfig file'
+
+	fi
+	
+	case "$quick" in
+	true)	return 0 ;;
+	false)	return 1 ;;
+	ask)	: do not return ;;
+	esac
+	
+	if ! test -t 0 || ! test -t 1
+	then
+		return 0
+	fi
+	
+	printf 'Do you want to create an unnamed stash? [Y/n] '
+	read reply
+	case "$reply" in
+	[nN]*)	return 1 ;;
+	*)	return 0 ;;
+	esac
+}
+
 # Main command set
 case "$1" in
 list)
@@ -226,11 +289,16 @@ create)
 	create_stash "$*" && echo "$w_commit"
 	;;
 *)
-	if test $# -eq 0
+	if test $# -ne 0
+	then
+		usage
+	fi
+	if allow_quick_stash
 	then
 		save_stash && git-reset --hard
 	else
-		usage
+		echo "*** Stash List ***"
+		list_stash
 	fi
 	;;
 esac
--
1.5.3.7

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Find out how you can get spam free email.
http://www.bluebottle.com/tag/3

Re: git-stash: RFC: Adopt the default behavior to other commands

[Junio C Hamano]

しらいしななこ  <nanako3@bluebottle.com> writes:

> How about making this behavior configurable?

First, as a general principle, I'd like to avoid having commands that
changes their behaviour drastically depending on who the user is.  It
makes it harder for people experienced a bit more than totally new to
help others.  If they are truly experts and are familiar about the
configuration stash.quick, then they will be fine, but others would say
"Well, it works for me -- 'git stash' itself won't stash but list.  Why
isn't it working for you, I don't know" and scratch head.

Having said that, I reserve rights to change my mind later and start
liking this approach as a compromise.

There are a few suggestions and comments.

> +allow_quick_stash () {
> +	
> +	quick=$(git config stash.quick)
> +	if test $? != 0
> +	then

I think this is not a per-repository but per-person configuration (I
already said I do not want per-person configuration to affect the
fundamental behaviour of commands, but let's put that objection on hold
for now).  "git config --global" would be more appropriate.

So if the user hasn't seen this behaviour before, then...

> +		if ! test -t 0 || ! test -t 1
> +		then
> +			return 0
> +		fi

If it is not interactively called, allow "git stash" sans parameters as
before.  Nice attention to the details.

> +		echo '
> +*** First time users ***
> ...
> +		git config stash.quick $quick
> +		echo '
> +You can reconfigure this by editing your $HOME/.gitconfig file'
> +
> +	fi

Again, you would want --global here.  Also hint about explicit "save"
and "list" in addition to "you can reconfigure" might be helpful.

> +	case "$quick" in
> +	true)	return 0 ;;
> +	false)	return 1 ;;
> +	ask)	: do not return ;;
> +	esac
> +	
> +	if ! test -t 0 || ! test -t 1
> +	then
> +		return 0
> +	fi

Even if it is configured to 'ask', we allow it for non-interactive
session (aka scripts).  Although I would agree with this logic, it could
be debatable.

> @@ -226,11 +289,16 @@ create)
>  	create_stash "$*" && echo "$w_commit"
>  	;;
>  *)
> -	if test $# -eq 0
> +	if test $# -ne 0
> +	then
> +		usage
> +	fi
> +	if allow_quick_stash
>  	then
>  		save_stash && git-reset --hard
>  	else
> -		usage
> +		echo "*** Stash List ***"
> +		list_stash
>  	fi

I was scratching my head about this extra "echo" and tried your version
after removing it, to realize this is another nice attention to the
details.  Without it, what's output from the command is not very clear
to people who do not know what "git stash" is configured to do for the
session.

Re: git-stash: RFC: Adopt the default behavior to other commands

[Wincent Colaiuta]

El 20/12/2007, a las 23:31, Junio C Hamano escribió:

> しらいしななこ  <nanako3@bluebottle.com> writes:
>
>> How about making this behavior configurable?
>
> First, as a general principle, I'd like to avoid having commands that
> changes their behaviour drastically depending on who the user is.  It
> makes it harder for people experienced a bit more than totally new to
> help others.  If they are truly experts and are familiar about the
> configuration stash.quick, then they will be fine, but others would  
> say
> "Well, it works for me -- 'git stash' itself won't stash but list.   
> Why
> isn't it working for you, I don't know" and scratch head.

Although the patch is well-intentioned, I totally agree with Junio on  
this point.

The solution here isn't configuration, but education. Some people have  
already told how they've been burnt by doing an accidental stash, but  
how many times does this have to happen to you before you learn your  
lesson? Once? Twice if you are very unlucky?

And this is not a very painful lesson to learn, seeing as "git stash"  
is not an inherently destructive operation. In 99% of cases there is  
no risk of hard-to-reverse "damage". If you accidentally stash, you  
can just unstash with "git stash apply". I already posted a two-line  
patch which tells the user how to do this:

http://marc.info/?l=git&m=119799257404542&w=2

The 1% of cases in which "git stash apply" won't work is where the  
user has unsaved changes in running editors at the time they do the  
accidental stash. IMO, this is no justification to change the  
behaviour of stash. Exactly the same is true of other commands that  
alter the working tree; for example, what happens if you use "git  
checkout" to switch to another branch when you have unsaved changes in  
running editors? Are people suggesting that we should change the  
behaviour of "git checkout" to warn the user that they should save any  
unsaved changes before continuing and then hit "y"? I think that such  
a thing would be absurd.

Cheers,
Wincent

Re: git-stash: RFC: Adopt the default behavior to other commands

[しらいしななこ]

Quoting Junio C Hamano <gitster@pobox.com>:

> しらいしななこ  <nanako3@bluebottle.com> writes:
>
>> How about making this behavior configurable?
>
> First, as a general principle, I'd like to avoid having commands that
> changes their behaviour drastically depending on who the user is.  It
> makes it harder for people experienced a bit more than totally new to
> help others.  If they are truly experts and are familiar about the
> configuration stash.quick, then they will be fine, but others would say
> "Well, it works for me -- 'git stash' itself won't stash but list.  Why
> isn't it working for you, I don't know" and scratch head.

I see.  I usually am not the person who helps but am the 
person who is helped in such a situation, and did not 
consider this issue.

> Having said that, I reserve rights to change my mind later and start
> liking this approach as a compromise.

I will change the patch as you suggested and resubmit.  Let's 
see if I can change your mind (^_^).

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Free pop3 email with a spam filter.
http://www.bluebottle.com/tag/5

Re: git-stash: RFC: Adopt the default behavior to other commands

[André Goddard Rosa]

On Dec 18, 2007 1:42 PM, Jörg Sommer <joerg@alea.gnuu.de> wrote:
> Hi,
>
> Junio C Hamano schrieb am Mon 17. Dec, 16:31 (-0800):
> > Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> >
> > >> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> > >>
> > >>> ...  The current behavior of git stash is very
> > >>> dangerous ...
> > > ...
> > >> This is a plain FUD, isn't it?  The first Oops should not happen these
> > >> days.
> >
> > But the original point by Sebastian hasn't been answered.  He wanted to
> > make the command list the stash without arguments.
> >
> > This was discussed already in the early days of stash and there indeed
> > was a suggestion to do so (I think I sided with that), but the users did
> > not want it.  IIRC, the argument went like: "when I say 'stash', that is
> > because I want a quick and immediate way to stash, and I do not want a
> > list.  If I do not have to have a quick way, I would create a temporary
> > commit on the current branch, or switch to a temporary branch and commit
> > there."
>
> When it should go quick why don't use an alias. git stash can print the
> list and everyone who wants a quick stash can create an alias for this.
>
> I vote for stash print the list, because I dropped in the pitfall.
>

I got caught by this default too. One vote more!

Regards,
-- 
[]s,
André Goddard

Re: git-stash: RFC: Adopt the default behavior to other commands

[Martin Langhoff]

On Dec 19, 2007 4:42 AM, Jörg Sommer <joerg@alea.gnuu.de> wrote:
> I vote for stash print the list, because I dropped in the pitfall.

I've dropped there myself, and work with a large team where we are
both fans of stash, and scarred by it. Any newcomer to git that
"discovers" stash gets hit by it a dozen times, this is completely
unnecesary.

All state-changing commands need parameters or are interactive (as
it's the case with git-commit). That Johannes & early adopters,
including me, have gotten used to the unintuitive (and dangerously
surprising) behaviour of stash is no excuse to inflict it upon actual
end users. It's way too early for git and the stash command to stick
to a misfeature in the name of backwards compat. We'll adapt, as we
have in the past, to an evolving ui.

And if -- in a new repo -- the list is empty, we can just say so:
Nothing has been stashed yet. Which looks completely different from a
successful stash 'save' command.

cheers,


m

Re: git-stash: RFC: Adopt the default behavior to other commands

[Wincent Colaiuta]

El 19/12/2007, a las 0:41, Martin Langhoff escribió:

> On Dec 19, 2007 4:42 AM, Jörg Sommer <joerg@alea.gnuu.de> wrote:
>> I vote for stash print the list, because I dropped in the pitfall.
>
> I've dropped there myself, and work with a large team where we are
> both fans of stash, and scarred by it. Any newcomer to git that
> "discovers" stash gets hit by it a dozen times, this is completely
> unnecesary.

I may be missing something here, but what's the danger here? An  
unexpected stash is incredibly easy to revert, unless I'm missing  
something. And nobody commented on the idea I posted earlier which  
seems to address the concerns about newbies not knowing what "git  
stash" with no params does:

http://marc.info/?l=git&m=119799257404542&w=2

Cheers,
Wincent

Re: git-stash: RFC: Adopt the default behavior to other commands

[Martin Langhoff]

On Dec 19, 2007 8:33 PM, Wincent Colaiuta <win@wincent.com> wrote:
> El 19/12/2007, a las 0:41, Martin Langhoff escribió:
>
> > On Dec 19, 2007 4:42 AM, Jörg Sommer <joerg@alea.gnuu.de> wrote:
> >> I vote for stash print the list, because I dropped in the pitfall.
> >
> > I've dropped there myself, and work with a large team where we are
> > both fans of stash, and scarred by it. Any newcomer to git that
> > "discovers" stash gets hit by it a dozen times, this is completely
> > unnecesary.
>
> I may be missing something here, but what's the danger here? An

Surprise. Your working directory has *just* changed under your feet.
Maybe you have an editor with further unsaved changes that is about to
act confused whether you undo the stash or not.

> unexpected stash is incredibly easy to revert, unless I'm missing

Once you know about it, yes it is. Once you know about the reflog, you
can sing and dance and never be worried. But for starting users, it's
a dangerous command.

> And nobody commented on the idea I posted earlier which
> seems to address the concerns about newbies not knowing what "git
> stash" with no params does:

I agree with making stash more verbose -- if the unlucky new user is
paying close attention, they'll have instructions on to how to get out
of trouble. But I agree more with making it "just verbose, no action"
by default. There are two strong hints:

 - all other state-changing commands take parameters
 - quite a few people in this list have gotten burned with it

Even after knowing pretty well how stash works, I still get mixed up
sometimes with the 'clear/clean/list' stuff. Or have a typo in the
command.

cheers,


martin

Re: git-stash: RFC: Adopt the default behavior to other commands

[Andreas Ericsson]

Martin Langhoff wrote:
> On Dec 19, 2007 8:33 PM, Wincent Colaiuta <win@wincent.com> wrote:
>> El 19/12/2007, a las 0:41, Martin Langhoff escribió:
>>
>>> On Dec 19, 2007 4:42 AM, Jörg Sommer <joerg@alea.gnuu.de> wrote:
>>>> I vote for stash print the list, because I dropped in the pitfall.
>>> I've dropped there myself, and work with a large team where we are
>>> both fans of stash, and scarred by it. Any newcomer to git that
>>> "discovers" stash gets hit by it a dozen times, this is completely
>>> unnecesary.
>> I may be missing something here, but what's the danger here? An
> 
> Surprise. Your working directory has *just* changed under your feet.
> Maybe you have an editor with further unsaved changes that is about to
> act confused whether you undo the stash or not.
> 
>> unexpected stash is incredibly easy to revert, unless I'm missing
> 
> Once you know about it, yes it is. Once you know about the reflog, you
> can sing and dance and never be worried. But for starting users, it's
> a dangerous command.
> 
>> And nobody commented on the idea I posted earlier which
>> seems to address the concerns about newbies not knowing what "git
>> stash" with no params does:
> 
> I agree with making stash more verbose -- if the unlucky new user is
> paying close attention, they'll have instructions on to how to get out
> of trouble. But I agree more with making it "just verbose, no action"
> by default. There are two strong hints:
> 
>  - all other state-changing commands take parameters
>  - quite a few people in this list have gotten burned with it
> 
> Even after knowing pretty well how stash works, I still get mixed up
> sometimes with the 'clear/clean/list' stuff. Or have a typo in the
> command.
> 

The clear vs clean confusion has been remedied though, and you can no
longer create a named stash without using "git stash save" with a
recent enough version of git.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git-stash: RFC: Adopt the default behavior to other commands

[Johannes Schindelin]

Hi,

On Wed, 19 Dec 2007, Martin Langhoff wrote:

> On Dec 19, 2007 8:33 PM, Wincent Colaiuta <win@wincent.com> wrote:
> > El 19/12/2007, a las 0:41, Martin Langhoff escribi?:
> >
> > > On Dec 19, 2007 4:42 AM, J?rg Sommer <joerg@alea.gnuu.de> wrote:
> > >> I vote for stash print the list, because I dropped in the pitfall.
> > >
> > > I've dropped there myself, and work with a large team where we are 
> > > both fans of stash, and scarred by it. Any newcomer to git that 
> > > "discovers" stash gets hit by it a dozen times, this is completely 
> > > unnecesary.
> >
> > I may be missing something here, but what's the danger here? An
> 
> Surprise. Your working directory has *just* changed under your feet. 
> Maybe you have an editor with further unsaved changes that is about to 
> act confused whether you undo the stash or not.

The funny thing: why do you call stash with unsaved changes anyway?  I 
mean, come on, even if you were planning to see the usage of stash (which 
you would get with -h), you undoubtedly wanted to either stash or unstash 
some changes.  Otherwise you would not _need_ to see the usage to begin 
with.

> > unexpected stash is incredibly easy to revert, unless I'm missing
> 
> Once you know about it, yes it is. Once you know about the reflog, you
> can sing and dance and never be worried. But for starting users, it's
> a dangerous command.

No.

Reflogs have nothing to do with it.

If you want to stash changes, you _got_ to know how to unstash those 
changes.  Otherwise "git reset --hard" would have been your friend.

And so, I cannot help but believe that all users of stash -- even the new 
ones -- know about the fundamental concept of stashing/unstashing, and 
therefore it is more something like this:

	$ git stash
	[no usage?  What the heck... Oh, it stashed the changes.  I did 
	 not want to stash them just yet.  Okay:]
	$ git unstash
	No such command
	[Oh, maybe I should have read the man page.  Oh, well, the usage 
	 should do...]
	$ git stash -h
	...

Yes, if you start "git stash" blindly, believing that it does what "git 
stash -h" does, you will be bitten by it once.

But as I said, you will be bitten by a plenty commands if you are not 
familiar with the concept that "-h" shows the synopsis, "--help" the man 
page, and that there is a default action where possible.

But stash really is about things like

	$ git stash
	$ git pull
	$ git stash apply

I do not _want_ to see the stash list in _most_ cases, because I do not 
stash away million dirty changes.

And that workflow was what "git stash" was designed for.

> > And nobody commented on the idea I posted earlier which seems to 
> > address the concerns about newbies not knowing what "git stash" with 
> > no params does:
> 
> I agree with making stash more verbose -- if the unlucky new user is
> paying close attention, they'll have instructions on to how to get out
> of trouble. But I agree more with making it "just verbose, no action"
> by default. There are two strong hints:
> 
>  - all other state-changing commands take parameters

What about "git commit", "git reset", "git fetch"?  These definitely 
change state of the repository.

>  - quite a few people in this list have gotten burned with it

Okay, let's have a little calculation: IIRC 3 people (let's make it 10, to 
be conservative) have said that they had this problem.  I must assume that 
all other people did not have the problem, or at least saw why the default 
action of "git stash" is what it is.

That said, if you _have_ to have the default changed, then I'll probably 
implement a "git push" and "git pop" alias here, so that I cannot get 
annoyed by stash's "new and improved" behaviour.

Ciao,
Dscho

Re: git-stash: RFC: Adopt the default behavior to other commands

[Wincent Colaiuta]

El 19/12/2007, a las 13:01, Johannes Schindelin escribió:

> But stash really is about things like
>
> 	$ git stash
> 	$ git pull
> 	$ git stash apply
>
> I do not _want_ to see the stash list in _most_ cases, because I do  
> not
> stash away million dirty changes.
>
> And that workflow was what "git stash" was designed for.

+1.

Wincent