Feature: git stash pop --always-drop

Feature: git stash pop --always-drop

[Ed Avis]

I would find it useful to ask 'git stash pop' to always drop the stash after
applying it to the working tree, even if there were conflicts.  (Only if there
was some hard error, such as an I/O error updating some of the files, should
the stash be left on the stack.)

Would a patch for such an --always-drop flag be accepted?

-- 
Ed Avis <eda@waniasset.com>

Re: Feature: git stash pop --always-drop

[Jeff King]

On Mon, Aug 10, 2015 at 10:42:30AM +0000, Ed Avis wrote:

> I would find it useful to ask 'git stash pop' to always drop the stash after
> applying it to the working tree, even if there were conflicts.  (Only if there
> was some hard error, such as an I/O error updating some of the files, should
> the stash be left on the stack.)

Hmm. That seems rather dangerous, but hey, if it's not the default, I
guess it is your own foot that you are shooting.

> Would a patch for such an --always-drop flag be accepted?

I doubt you will get a good answer to that question; the attitude here
is usually "well, we would have to see the patch". For instance, I don't
know how easy it will be to tell merge conflicts apart from I/O errors.
Figuring that out will probably be part of a rough draft patch.

-Peff

Re: Feature: git stash pop --always-drop

[Ed Avis]

An alternative would be for git stash to always print the name of the stash
it is applying.  Then you can drop it afterwards by name and be sure you got
the right one.  Printing the name of the stash sounds like a reasonable
bit of chatter to add anyway, do you agree?

-- 
Ed Avis <eda@waniasset.com>

Re: Feature: git stash pop --always-drop

[Jeff King]

On Mon, Aug 10, 2015 at 12:50:51PM +0000, Ed Avis wrote:

> An alternative would be for git stash to always print the name of the stash
> it is applying.  Then you can drop it afterwards by name and be sure you got
> the right one.  Printing the name of the stash sounds like a reasonable
> bit of chatter to add anyway, do you agree?

Yeah, I agree that makes sense. We already show something like:

  Dropped refs/stash@{0} (31cb86c3d700d241e315d989f460e3e83f84fa19)

when dropping. Perhaps model the message after that:

  Applying refs/stash@{0} (31cb86c3d700d241e315d989f460e3e83f84fa19)

Or maybe it would be useful to actually show the stash subject, though
the defaults are not very informative (just "WIP on master", and then
some totally irrelevant commit subject).

-Peff

Re: Feature: git stash pop --always-drop

[Ed Avis]

Jeff King <peff <at> peff.net> writes:

>>An alternative would be for git stash to always print the name of the stash
>>it is applying.

>  Applying refs/stash@{0} (31cb86c3d700d241e315d989f460e3e83f84fa19)

Yes, that's the one.

>Or maybe it would be useful to actually show the stash subject,

That could be nice to see, but is not a substitute for the SHA.

If the stash pop failed because of conflicts then it could even print

    To drop this stash manually, run 'git stash drop abcde...'

Another feature I would like to see is a kind of atomic stash apply, where
either the whole change can be applied to the working tree without conflicts,
or nothing happens.

-- 
Ed Avis <eda@waniasset.com>

Re: Feature: git stash pop --always-drop

[Jeff King]

On Mon, Aug 10, 2015 at 01:43:07PM +0000, Ed Avis wrote:

> Jeff King <peff <at> peff.net> writes:
> 
> >>An alternative would be for git stash to always print the name of the stash
> >>it is applying.
> 
> >  Applying refs/stash@{0} (31cb86c3d700d241e315d989f460e3e83f84fa19)
> 
> Yes, that's the one.
> 
> >Or maybe it would be useful to actually show the stash subject,
> 
> That could be nice to see, but is not a substitute for the SHA.

I think you'd be _technically_ OK without the sha1 in the "applying
message", because you can refer to it as stash@{0} until it is dropped,
and the drop message does mention the sha1. But that seems needlessly
complicated for the user. I agree that including the sha1 is reasonable
(though we might want to use an abbreviated one if there is other stuff
to go on the line).

> If the stash pop failed because of conflicts then it could even print
> 
>     To drop this stash manually, run 'git stash drop abcde...'

Yup, that makes sense. You might want to make it optional an advice.*
config key, though. I also wondered if the "dropped" message is
sufficiently clear to new users. The point of it, I think, is to allow a
final "oops, I didn't mean to do that" moment. But there are no
instructions for how one would re-create the same stash.

It might be that showing instructions on even successful drops would
quickly get annoying, though. I dunno. I tend to turn off most of our
advice config myself.

> Another feature I would like to see is a kind of atomic stash apply, where
> either the whole change can be applied to the working tree without conflicts,
> or nothing happens.

I think that may be a bit harder, as the merge machinery would have to
know how to be atomic. Still, I agree it's a good goal if you'd like to
work on it.

-Peff

Re: Feature: git stash pop --always-drop

[Ed Avis]

>
Yes, my use case is that I get confused about whether the stash has been
dropped or not and whether I might have stashed something else in the
meantime.  So for me plain 'git stash drop' feels a bit dangerous.

Jeff King <peff <at> peff.net> writes:

>I also wondered if the "dropped" message is
>sufficiently clear to new users. The point of it, I think, is to allow a
>final "oops, I didn't mean to do that" moment. But there are no
>instructions for how one would re-create the same stash.

Right - myself I didn't even realize that recreating the stash was possible
(though I was vaguely aware that old stashes float around somewhere until
they are garbage collected many months later).

git stash is a relatively infrequent operation and quite exotic, so it
wouldn't hurt to add lots of chatter to it.

>>Another feature I would like to see is a kind of atomic stash apply, 

>I think that may be a bit harder, as the merge machinery would have to
>know how to be atomic.

If git merge-recursive had a --dry-run flag that might take care of it.

-- 
Ed Avis <eda@waniasset.com>

Re: Feature: git stash pop --always-drop

[Junio C Hamano]

Ed Avis <eda@waniasset.com> writes:

> Yes, my use case is that I get confused about whether the stash has been
> dropped or not and whether I might have stashed something else in the
> meantime.  So for me plain 'git stash drop' feels a bit dangerous.

Then "git stash apply" followed by "git stash drop" would be a pair
of good workflow elements for you, no?

Re: Feature: git stash pop --always-drop

[Ed Avis]

Junio C Hamano <gitster <at> pobox.com> writes:
 
>>Yes, my use case is that I get confused about whether the stash has been
>>dropped or not and whether I might have stashed something else in the
>>meantime.  So for me plain 'git stash drop' feels a bit dangerous.
>
>Then "git stash apply" followed by "git stash drop" would be a pair
>of good workflow elements for you, no?

I like ordinary 'git stash pop' when it applies cleanly.  Only in the cases
where it has conflicts and leaves the stash in place does it get a bit
awkward.  I manually resolve the conflicts and then 'git stash drop', but
that last step is a bit dangerous because it might drop an unrelated stash
if I have done some other stashing in the meantime.

If 'git stash pop' (and 'apply') would always print the name of the stash,
then it would be easy to drop that particular stash afterwards.  Running
one too many or one too few 'git stash drop' commands would no longer cause
problems.

Printing the name of the stash would, for me, largely remove the need for
an --always-drop option to git stash, which is what I at first suggested.

-- 
Ed Avis <eda@waniasset.com>