[RFC] stash --continue

[RFC] stash --continue

[Stephan Beyer]

Hi,

a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
"git stash pop", he got into a merge conflict. After he resolved the
conflict, he did not know what to do to get the repository into the
wanted state. In his case, it was only "git add <resolved files>"
followed by a "git reset" and a "git stash drop", but there may be more
involved cases when your index is not clean before "git stash pop" and
you want to have your index as before.

This led to the idea to have something like "git stash --continue"[1]
that would expect the user to "git add" the resolved files (as "git
status" suggests) but then leads to the expected result, i.e. the index
being the same as before the conflict, the stash being dropped (if "pop"
was used instead of "apply"), etc.

Likewise, some "git stash --abort"[2] might be useful in case you did
"git stash pop" with the wrong stash in mind.

What do you think about that?

Although I think this would be a nice-to-have feature, I am not totally
sure how to achieve backwards-compatibility, i.e., such that using
--continue is still optional... (I think that "git stash apply" would
surely generate auxiliary data in case of a conflict and --continue or
--abort would remove it...)

Best
  Stephan

Footnotes
1. Perhaps with a better name, because it does not really continue.
Maybe a "git stash conflict [--resolved]" subcommand?
2. Along the lines of [1], one could use "git stash conflict --abort"?

Re: [RFC] stash --continue

[Jacob Keller]

On Sun, Jan 15, 2017 at 3:56 PM, Stephan Beyer <s-beyer@gmx.net> wrote:
> Hi,
>
> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
> "git stash pop", he got into a merge conflict. After he resolved the
> conflict, he did not know what to do to get the repository into the
> wanted state. In his case, it was only "git add <resolved files>"
> followed by a "git reset" and a "git stash drop", but there may be more
> involved cases when your index is not clean before "git stash pop" and
> you want to have your index as before.
>
> This led to the idea to have something like "git stash --continue"[1]
> that would expect the user to "git add" the resolved files (as "git
> status" suggests) but then leads to the expected result, i.e. the index
> being the same as before the conflict, the stash being dropped (if "pop"
> was used instead of "apply"), etc.
>
> Likewise, some "git stash --abort"[2] might be useful in case you did
> "git stash pop" with the wrong stash in mind.
>
> What do you think about that?
>

This sounds like a useful extension to me.

Thanks,
Jake

Re: [RFC] stash --continue

[Johannes Schindelin]

Hi Stephan,

On Mon, 16 Jan 2017, Stephan Beyer wrote:

> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
> "git stash pop", he got into a merge conflict. After he resolved the
> conflict, he did not know what to do to get the repository into the
> wanted state. In his case, it was only "git add <resolved files>"
> followed by a "git reset" and a "git stash drop", but there may be more
> involved cases when your index is not clean before "git stash pop" and
> you want to have your index as before.
> 
> This led to the idea to have something like "git stash --continue"[1]

More like "git stash pop --continue". Without the "pop" command, it does
not make too much sense.

Ciao,
Johannes

Re: [RFC] stash --continue

[Marc Branchaud]

On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
> Hi Stephan,
>
> On Mon, 16 Jan 2017, Stephan Beyer wrote:
>
>> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
>> "git stash pop", he got into a merge conflict. After he resolved the
>> conflict, he did not know what to do to get the repository into the
>> wanted state. In his case, it was only "git add <resolved files>"
>> followed by a "git reset" and a "git stash drop", but there may be more
>> involved cases when your index is not clean before "git stash pop" and
>> you want to have your index as before.
>>
>> This led to the idea to have something like "git stash --continue"[1]
>
> More like "git stash pop --continue". Without the "pop" command, it does
> not make too much sense.

Why not?  git should be able to remember what stash command created the 
conflict.  Why should I have to?  Maybe the fire alarm goes off right 
when I run the stash command, and by the time I get back to it I can't 
remember which operation I did.  It would be nice to be able to tell git 
to "just finish off (or abort) the stash operation, whatever it was".

		M.

Re: [RFC] stash --continue

[Johannes Schindelin]

Hi Marc,

On Wed, 18 Jan 2017, Marc Branchaud wrote:

> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
>
> > On Mon, 16 Jan 2017, Stephan Beyer wrote:
> >
> > > a git-newbie-ish co-worker uses git-stash sometimes. Last time he
> > > used "git stash pop", he got into a merge conflict. After he
> > > resolved the conflict, he did not know what to do to get the
> > > repository into the wanted state. In his case, it was only "git add
> > > <resolved files>" followed by a "git reset" and a "git stash drop",
> > > but there may be more involved cases when your index is not clean
> > > before "git stash pop" and you want to have your index as before.
> > >
> > > This led to the idea to have something like "git stash
> > > --continue"[1]
> >
> > More like "git stash pop --continue". Without the "pop" command, it
> > does not make too much sense.
> 
> Why not?  git should be able to remember what stash command created the
> conflict.  Why should I have to?  Maybe the fire alarm goes off right when I
> run the stash command, and by the time I get back to it I can't remember
> which operation I did.  It would be nice to be able to tell git to "just
> finish off (or abort) the stash operation, whatever it was".

That reeks of a big potential for confusion.

Imagine for example a total Git noob who calls `git stash list`, scrolls
two pages down, then hits `q` by mistake. How would you explain to that
user that `git stash --continue` does not continue showing the list at the
third page?

Even worse: `git stash` (without arguments) defaults to the `save`
operation, so any user who does not read the documentation (and who does?)
would assume that `git stash --continue` *also* implies `save`.

If that was not enough, there would still be the overall design of Git's
user interface. You can call it confusing, inconsistent, with a lot of
room for improvement, and you would be correct. But none of Git's commands
has a `--continue` option that remembers the latest subcommand and
continues that. To introduce that behavior in `git stash` would disimprove
the situation.

With every new feature, it is not enough to consider its benefits. You
always have to take the potential fallout into account, too.

At least `git stash pop --continue` would be consistent with all other
`--continue` options in Git that I can think of...

Ciao,
Johannes

Re: [RFC] stash --continue

[Marc Branchaud]

On 2017-01-18 11:34 AM, Johannes Schindelin wrote:
> Hi Marc,
>
> On Wed, 18 Jan 2017, Marc Branchaud wrote:
>
>> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
>>
>>> On Mon, 16 Jan 2017, Stephan Beyer wrote:
>>>
>>>> a git-newbie-ish co-worker uses git-stash sometimes. Last time he
>>>> used "git stash pop", he got into a merge conflict. After he
>>>> resolved the conflict, he did not know what to do to get the
>>>> repository into the wanted state. In his case, it was only "git add
>>>> <resolved files>" followed by a "git reset" and a "git stash drop",
>>>> but there may be more involved cases when your index is not clean
>>>> before "git stash pop" and you want to have your index as before.
>>>>
>>>> This led to the idea to have something like "git stash
>>>> --continue"[1]
>>>
>>> More like "git stash pop --continue". Without the "pop" command, it
>>> does not make too much sense.
>>
>> Why not?  git should be able to remember what stash command created the
>> conflict.  Why should I have to?  Maybe the fire alarm goes off right when I
>> run the stash command, and by the time I get back to it I can't remember
>> which operation I did.  It would be nice to be able to tell git to "just
>> finish off (or abort) the stash operation, whatever it was".
>
> That reeks of a big potential for confusion.
>
> Imagine for example a total Git noob who calls `git stash list`, scrolls
> two pages down, then hits `q` by mistake. How would you explain to that
> user that `git stash --continue` does not continue showing the list at the
> third page?

Sorry, but I have trouble taking that example seriously.  It assumes 
such a level of "noobness" that the user doesn't even understand how 
standard command output paging works, not just with git but with any 
shell command.

> Even worse: `git stash` (without arguments) defaults to the `save`
> operation, so any user who does not read the documentation (and who does?)
> would assume that `git stash --continue` *also* implies `save`.

Like the first example, your user is trying to "continue" a command that 
is already complete.  It's like try to do "git rebase --continue" when 
there's no rebase operation underway.

Now, maybe there is some way for "git stash save" (implied or explicit) 
to stop partway through the operation.  I can't imagine such a situation 
(out of disk space, maybe?), particularly where the user would expect 
"git stash save" to leave things in a half-finished state.  To me "git 
stash save" should be essentially all-or-nothing.

However, if there were such a partial-failure scenario, then I think it 
would be perfectly reasonable for "git stash --continue" to finish the 
save operation, assuming that the failure condition has been resolved.

> If that was not enough, there would still be the overall design of Git's
> user interface. You can call it confusing, inconsistent, with a lot of
> room for improvement, and you would be correct. But none of Git's commands
> has a `--continue` option that remembers the latest subcommand and
> continues that. To introduce that behavior in `git stash` would disimprove
> the situation.

I think it's more the case that none of the current continuable commands 
have subcommands (though I can't think of all the continuable or 
abortable operations offhand, so maybe I'm wrong).  I think we're 
discussing new UI ground here.

And since the pattern is already "git foo --continue", it seems more 
consistent to me for it to be "git stash --continue" as well. 
Especially since there can be only one partially-complete stash 
sub-operation at one time (per workdir, at least).  So there's no reason 
to change the pattern just for the stash command.

Think of it this way:  All the currently continuable/abortable commands 
put the repository in a shaky state, where performing certain other 
operations would be ill advised.  Attempting to start a rebase while a 
merge conflict is unresolved, for example.  IIRC, git actually tries to 
stop users from shooting their feet in this way.

And so it should be for the stash operation:  If applying a stash yields 
a conflict, it has to be resolved or aborted before something like a 
rebase or merge is attempted.  It doesn't matter which stash subcommand 
created the shaky situation.

In the long run, I think there's even the possibility of generic "git 
continue" and "git abort" commands, that simply continue or abort the 
current partially-complete operation, whatever it is.  (Isn't that the 
ultimate goal of all the "sequencer" work?  I admit I have not been 
following that effort.)

> With every new feature, it is not enough to consider its benefits. You
> always have to take the potential fallout into account, too.

Agreed.

> At least `git stash pop --continue` would be consistent with all other
> `--continue` options in Git that I can think of...

Alas, I disagree!

		M.

Re: [RFC] stash --continue

[Samuel Lijin]

>> At least `git stash pop --continue` would be consistent with all other
>> `--continue` options in Git that I can think of...

> Alas, I disagree!

I'm with Johannes here. "git stash" sans subcommand is pretty
explicitly defined as "git stash save", so by similar logic, "git
stash --continue", if anything, would be "git stash save --continue".

I do agree that there's a slight problem with hunting down consistency
in implementations of --continue since there aren't other usages that
involve subcommands (rebase, cp, merge) but I can't think of "git
stash" as a completely specified command, whereas I do see "git stash
pop" and "git stash apply" as completely specified.

On Wed, Jan 18, 2017 at 12:44 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:
> On 2017-01-18 11:34 AM, Johannes Schindelin wrote:
>>
>> Hi Marc,
>>
>> On Wed, 18 Jan 2017, Marc Branchaud wrote:
>>
>>> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
>>>
>>>> On Mon, 16 Jan 2017, Stephan Beyer wrote:
>>>>
>>>>> a git-newbie-ish co-worker uses git-stash sometimes. Last time he
>>>>> used "git stash pop", he got into a merge conflict. After he
>>>>> resolved the conflict, he did not know what to do to get the
>>>>> repository into the wanted state. In his case, it was only "git add
>>>>> <resolved files>" followed by a "git reset" and a "git stash drop",
>>>>> but there may be more involved cases when your index is not clean
>>>>> before "git stash pop" and you want to have your index as before.
>>>>>
>>>>> This led to the idea to have something like "git stash
>>>>> --continue"[1]
>>>>
>>>>
>>>> More like "git stash pop --continue". Without the "pop" command, it
>>>> does not make too much sense.
>>>
>>>
>>> Why not?  git should be able to remember what stash command created the
>>> conflict.  Why should I have to?  Maybe the fire alarm goes off right
>>> when I
>>> run the stash command, and by the time I get back to it I can't remember
>>> which operation I did.  It would be nice to be able to tell git to "just
>>> finish off (or abort) the stash operation, whatever it was".
>>
>>
>> That reeks of a big potential for confusion.
>>
>> Imagine for example a total Git noob who calls `git stash list`, scrolls
>> two pages down, then hits `q` by mistake. How would you explain to that
>> user that `git stash --continue` does not continue showing the list at the
>> third page?
>
>
> Sorry, but I have trouble taking that example seriously.  It assumes such a
> level of "noobness" that the user doesn't even understand how standard
> command output paging works, not just with git but with any shell command.
>
>> Even worse: `git stash` (without arguments) defaults to the `save`
>> operation, so any user who does not read the documentation (and who does?)
>> would assume that `git stash --continue` *also* implies `save`.
>
>
> Like the first example, your user is trying to "continue" a command that is
> already complete.  It's like try to do "git rebase --continue" when there's
> no rebase operation underway.
>
> Now, maybe there is some way for "git stash save" (implied or explicit) to
> stop partway through the operation.  I can't imagine such a situation (out
> of disk space, maybe?), particularly where the user would expect "git stash
> save" to leave things in a half-finished state.  To me "git stash save"
> should be essentially all-or-nothing.
>
> However, if there were such a partial-failure scenario, then I think it
> would be perfectly reasonable for "git stash --continue" to finish the save
> operation, assuming that the failure condition has been resolved.
>
>> If that was not enough, there would still be the overall design of Git's
>> user interface. You can call it confusing, inconsistent, with a lot of
>> room for improvement, and you would be correct. But none of Git's commands
>> has a `--continue` option that remembers the latest subcommand and
>> continues that. To introduce that behavior in `git stash` would disimprove
>> the situation.
>
>
> I think it's more the case that none of the current continuable commands
> have subcommands (though I can't think of all the continuable or abortable
> operations offhand, so maybe I'm wrong).  I think we're discussing new UI
> ground here.
>
> And since the pattern is already "git foo --continue", it seems more
> consistent to me for it to be "git stash --continue" as well. Especially
> since there can be only one partially-complete stash sub-operation at one
> time (per workdir, at least).  So there's no reason to change the pattern
> just for the stash command.
>
> Think of it this way:  All the currently continuable/abortable commands put
> the repository in a shaky state, where performing certain other operations
> would be ill advised.  Attempting to start a rebase while a merge conflict
> is unresolved, for example.  IIRC, git actually tries to stop users from
> shooting their feet in this way.
>
> And so it should be for the stash operation:  If applying a stash yields a
> conflict, it has to be resolved or aborted before something like a rebase or
> merge is attempted.  It doesn't matter which stash subcommand created the
> shaky situation.
>
> In the long run, I think there's even the possibility of generic "git
> continue" and "git abort" commands, that simply continue or abort the
> current partially-complete operation, whatever it is.  (Isn't that the
> ultimate goal of all the "sequencer" work?  I admit I have not been
> following that effort.)
>
>> With every new feature, it is not enough to consider its benefits. You
>> always have to take the potential fallout into account, too.
>
>
> Agreed.
>
>> At least `git stash pop --continue` would be consistent with all other
>> `--continue` options in Git that I can think of...
>
>
> Alas, I disagree!
>
>                 M.
>

Re: [RFC] stash --continue

[Johannes Schindelin]

Hi Marc,

On Wed, 18 Jan 2017, Marc Branchaud wrote:

> On 2017-01-18 11:34 AM, Johannes Schindelin wrote:
> >
> > On Wed, 18 Jan 2017, Marc Branchaud wrote:
> >
> > > On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
> > >
> > > > On Mon, 16 Jan 2017, Stephan Beyer wrote:
> > > >
> > > > > a git-newbie-ish co-worker uses git-stash sometimes. Last time
> > > > > he used "git stash pop", he got into a merge conflict. After he
> > > > > resolved the conflict, he did not know what to do to get the
> > > > > repository into the wanted state. In his case, it was only "git
> > > > > add <resolved files>" followed by a "git reset" and a "git stash
> > > > > drop", but there may be more involved cases when your index is
> > > > > not clean before "git stash pop" and you want to have your index
> > > > > as before.
> > > > >
> > > > > This led to the idea to have something like "git stash
> > > > > --continue"[1]
> > > >
> > > > More like "git stash pop --continue". Without the "pop" command,
> > > > it does not make too much sense.
> > >
> > > Why not?  git should be able to remember what stash command created
> > > the conflict.  Why should I have to?  Maybe the fire alarm goes off
> > > right when I run the stash command, and by the time I get back to it
> > > I can't remember which operation I did.  It would be nice to be able
> > > to tell git to "just finish off (or abort) the stash operation,
> > > whatever it was".
> >
> > That reeks of a big potential for confusion.
> >
> > Imagine for example a total Git noob who calls `git stash list`,
> > scrolls two pages down, then hits `q` by mistake. How would you
> > explain to that user that `git stash --continue` does not continue
> > showing the list at the third page?
> 
> Sorry, but I have trouble taking that example seriously.  It assumes
> such a level of "noobness" that the user doesn't even understand how
> standard command output paging works, not just with git but with any
> shell command.

Yeah, well, I thought you understood what I meant.

The example was the best I could come up with quickly, and it only tried
to show that there are *other* stash operations that one might perceive
to happen at the same time as the "pop" operation, so your flimsical
comment "why not continue the latest operation" may very well be
ambiguous.

And if it is not ambiguous in "stash", it certainly will be in other Git
operations. And therefore, having a DWIM in "stash" to allow "--continue"
without any specific subcommand, but not having it in other Git commands,
is just a very poor user interface design. It is prone to confuse users,
which is always a hallmark of a bad user interface.

Hence my objection to "git stash --continue". No argument in favor of "git
stash --continue" I heard so far comes even close to being convincing.

> > Even worse: `git stash` (without arguments) defaults to the `save`
> > operation, so any user who does not read the documentation (and who
> > does?) would assume that `git stash --continue` *also* implies `save`.
> 
> Like the first example, your user is trying to "continue" a command that
> is already complete.

Says who? You may understand the semantics better than other users, but
who are you to judge?

But that's besides the point.

My point (which you did not quite understand) was that it can be ambiguous
what to continue when looking at *all* Git commands. To special-case "git
stash"'s user interface makes things more confusing, and therefore less
usable for everyone.

And even with `git stash apply`, you could construct a very plausible
scenario (which does not work yet, but we may want to make it work): if
`git stash apply` causes conflicts, and `git stash apply stash@{1}`
conflicts in a *different* set of files, why don't we allow the second
operation to succeed (adding its conflicts)?

That example is like `git cherry-pick -n` with two different commits, both
of which conflict with the current worktree, but in different files. Both
cherry-picks would do their job if called after one another, and the
result is a worktree with the *combined* conflicts. That is a legitimate
use case (which I happened to *actually* perform just the other day).

If we fix "git stash" (and there is no reason we should not), it would
also allow "git stash pop; git stash pop" to work with two stashes that
both conflict with the current worktree, just in different files.

So I challenge you to get less hung up on the *exact* example I present,
and to try to see through the example what the issue is that I am trying
to get at.

> > If that was not enough, there would still be the overall design of
> > Git's user interface. You can call it confusing, inconsistent, with a
> > lot of room for improvement, and you would be correct. But none of
> > Git's commands has a `--continue` option that remembers the latest
> > subcommand and continues that. To introduce that behavior in `git
> > stash` would disimprove the situation.
> 
> I think it's more the case that none of the current continuable commands
> have subcommands (though I can't think of all the continuable or
> abortable operations offhand, so maybe I'm wrong).  I think we're
> discussing new UI ground here.

Nope, we are not entering new UI ground here. The principle is clear with
the existing --continue options: you pass them to the same operation that
you want to continue. By that reasoning, "git stash --continue" should
continue the (implicit) "save" operation. But that is not at all what you
want.

> And since the pattern is already "git foo --continue",

But foo *is the operation*! By that reasoning, you should agree that "git
stash --continue" is *wrong*!

> Think of it this way:  All the currently continuable/abortable commands
> put the repository in a shaky state, where performing certain other
> operations would be ill advised.  Attempting to start a rebase while a
> merge conflict is unresolved, for example.  IIRC, git actually tries to
> stop users from shooting their feet in this way.
> 
> And so it should be for the stash operation:  If applying a stash yields
> a conflict, it has to be resolved or aborted before something like a
> rebase or merge is attempted.

That already happens, and I have no idea how you think this safe-guarding
has anything to do whether the "--continue" option makes sense in "git
stash", or only in "git stash pop".

> In the long run, I think there's even the possibility of generic "git
> continue" and "git abort" commands,

Wrong.

You can call "git cherry-pick" (and "git cherry-pick --continue") while
running a "git rebase -i".

You can run "git rebase", "git stash", "git cherry-pick" and many other
commands while running a "git bisect".

You can even run a "git rebase" or a "git cherry-pick" while resolving an
interrupted "git am".

Many, many examples that make it *impossible* for Git to know *what* you
want to continue, *what* you want to abort.

> > At least `git stash pop --continue` would be consistent with all other
> > `--continue` options in Git that I can think of...
> 
> Alas, I disagree!

Sure, you are free to disagree.

And syntactially, you are even correct: "git <something> <something-else>
--continue" is inconsistent with "git <something> --continue".

But semantically, i.e. when you look at the *meaning* of those
"<something>"s, you are incorrect: the "--continue" option always goes
with the *operation* that needs to be continued. Always, always, always.
If you continue a rebase, it is "git rebase --continue", *not* "git
--continue". If you continue a revert, it is "git revert --continue". And
so it should be for popping a stash: "git stash pop --continue". Because
the operation is specified by "git stash pop", not by "git stash". There
is really not much you can argue sanely about that.

Ciao,
Johannes

Re: [RFC] stash --continue

[Marc Branchaud]

On 2017-01-19 10:49 AM, Johannes Schindelin wrote:
> Hi Marc,
>
> On Wed, 18 Jan 2017, Marc Branchaud wrote:
>
>> On 2017-01-18 11:34 AM, Johannes Schindelin wrote:
>>>
>>> On Wed, 18 Jan 2017, Marc Branchaud wrote:
>>>
>>>> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
>>>>
>>>>> On Mon, 16 Jan 2017, Stephan Beyer wrote:
>>>>>
>>>>>> a git-newbie-ish co-worker uses git-stash sometimes. Last time
>>>>>> he used "git stash pop", he got into a merge conflict. After he
>>>>>> resolved the conflict, he did not know what to do to get the
>>>>>> repository into the wanted state. In his case, it was only "git
>>>>>> add <resolved files>" followed by a "git reset" and a "git stash
>>>>>> drop", but there may be more involved cases when your index is
>>>>>> not clean before "git stash pop" and you want to have your index
>>>>>> as before.
>>>>>>
>>>>>> This led to the idea to have something like "git stash
>>>>>> --continue"[1]
>>>>>
>>>>> More like "git stash pop --continue". Without the "pop" command,
>>>>> it does not make too much sense.
>>>>
>>>> Why not?  git should be able to remember what stash command created
>>>> the conflict.  Why should I have to?  Maybe the fire alarm goes off
>>>> right when I run the stash command, and by the time I get back to it
>>>> I can't remember which operation I did.  It would be nice to be able
>>>> to tell git to "just finish off (or abort) the stash operation,
>>>> whatever it was".
>>>
>>> That reeks of a big potential for confusion.
>>>
>>> Imagine for example a total Git noob who calls `git stash list`,
>>> scrolls two pages down, then hits `q` by mistake. How would you
>>> explain to that user that `git stash --continue` does not continue
>>> showing the list at the third page?
>>
>> Sorry, but I have trouble taking that example seriously.  It assumes
>> such a level of "noobness" that the user doesn't even understand how
>> standard command output paging works, not just with git but with any
>> shell command.
>
> Yeah, well, I thought you understood what I meant.
>
> The example was the best I could come up with quickly, and it only tried
> to show that there are *other* stash operations that one might perceive
> to happen at the same time as the "pop" operation, so your flimsical
> comment "why not continue the latest operation" may very well be
> ambiguous.
>
> And if it is not ambiguous in "stash", it certainly will be in other Git
> operations. And therefore, having a DWIM in "stash" to allow "--continue"
> without any specific subcommand, but not having it in other Git commands,
> is just a very poor user interface design. It is prone to confuse users,
> which is always a hallmark of a bad user interface.

Please don't underestimate the power of syntactic consistency in helping 
users achieve their goals.  Having some commands use "git foo 
--continue" while others use "git foo bar --continue" *will* confuse 
people, regardless of how logical the reasons for those differences.

But in the case of stash, I still don't see the utility in having 
operation-specific continuation.  Consider the following sequence (as 
you say, this doesn't work yet, but making it work seems reasonable):

	git stash pop  # creates some conflicts
	git stash apply stash@{4} # creates some other conflicts
	# (User resolves the conflicts created by the pop.)
	git stash pop --continue

Given the description of the original proposal (do "git reset; git stash 
drop"), what's the state of the index and the working tree?

In particular, what has the user gained by continuing just that pop?

Another thing to ask is, how common is such a scenario likely to be?  I 
suggest that it will be far more common for users to resolve all the 
conflicts and then want to continue all their interrupted stash 
operations.  If so, fussily forcing them to explicitly continue the pop 
and the apply is just a waste.

> Hence my objection to "git stash --continue". No argument in favor of "git
> stash --continue" I heard so far comes even close to being convincing.

Well, what about the potential for a slippery slope?  If the user is 
forced to be specific about continuing either a pop or an apply, why 
wouldn't git allow them to be specific about *which* pop or apply they 
want to continue?  Consider another hypothetical scenario:

	git stash pop  # creates some conflicts
	git stash pop  # creates some more conflicts
	git stash pop  # creates even more conflicts
	# (User resolves the conflicts created by second pop.)
	git stash pop --continue
	# Oops, there's still some unresovled pops!

Obviously the user isn't ready to finish off all the pops, so they'll 
want some way to specify which pop to continue.  Dealing with that just 
feels like a lot of work for minimal benefit.

>>> Even worse: `git stash` (without arguments) defaults to the `save`
>>> operation, so any user who does not read the documentation (and who
>>> does?) would assume that `git stash --continue` *also* implies `save`.
>>
>> Like the first example, your user is trying to "continue" a command that
>> is already complete.
>
> Says who? You may understand the semantics better than other users, but
> who are you to judge?
>
> But that's besides the point.
>
> My point (which you did not quite understand) was that it can be ambiguous
> what to continue when looking at *all* Git commands. To special-case "git
> stash"'s user interface makes things more confusing, and therefore less
> usable for everyone.
>
> And even with `git stash apply`, you could construct a very plausible
> scenario (which does not work yet, but we may want to make it work): if
> `git stash apply` causes conflicts, and `git stash apply stash@{1}`
> conflicts in a *different* set of files, why don't we allow the second
> operation to succeed (adding its conflicts)?

Running those two commands should be perfectly fine.  The interesting 
question is what it means to *continue* from that state.

> That example is like `git cherry-pick -n` with two different commits, both
> of which conflict with the current worktree, but in different files. Both
> cherry-picks would do their job if called after one another, and the
> result is a worktree with the *combined* conflicts. That is a legitimate
> use case (which I happened to *actually* perform just the other day).

I don't mean to suggest that you shouldn't be able to do that.

> If we fix "git stash" (and there is no reason we should not), it would
> also allow "git stash pop; git stash pop" to work with two stashes that
> both conflict with the current worktree, just in different files.

Sounds fine to me.  So, what would it mean to continue from that state?

> So I challenge you to get less hung up on the *exact* example I present,
> and to try to see through the example what the issue is that I am trying
> to get at.
>
>>> If that was not enough, there would still be the overall design of
>>> Git's user interface. You can call it confusing, inconsistent, with a
>>> lot of room for improvement, and you would be correct. But none of
>>> Git's commands has a `--continue` option that remembers the latest
>>> subcommand and continues that. To introduce that behavior in `git
>>> stash` would disimprove the situation.
>>
>> I think it's more the case that none of the current continuable commands
>> have subcommands (though I can't think of all the continuable or
>> abortable operations offhand, so maybe I'm wrong).  I think we're
>> discussing new UI ground here.
>
> Nope, we are not entering new UI ground here. The principle is clear with
> the existing --continue options: you pass them to the same operation that
> you want to continue. By that reasoning, "git stash --continue" should
> continue the (implicit) "save" operation. But that is not at all what you
> want.
>
>> And since the pattern is already "git foo --continue",
>
> But foo *is the operation*! By that reasoning, you should agree that "git
> stash --continue" is *wrong*!

No, in the user's mind *stash* is the operation!  The user is doing 
"stash" stuff.  She doesn't care if the conflicts came from a pop or an 
apply.  She has resolved the conflicts, and now she just wants to continue.

There's no confusion about possibly continuing some other stash 
subcommand, like save or list or drop.  None of those other commands are 
continuable.  In the following sequence

	git stash "let me save my work now"
	git stash --continue

That continue command does nothing, regardless of whether the implied 
save command succeeded or failed.  There's simply nothing to continue.

With the sequence

	git stash pop  # creates some conflicts
	git stash "got some popped conflicts"
	git stash --continue

Again the continue command should do nothing:  If the save command 
succeeded it should have cleaned up the interrupted pop.  If the save 
command failed, then the continue command can't continue from a 
conflicted state.  (OTOH, a "git stash --abort" would abort the pop.)

>> Think of it this way:  All the currently continuable/abortable commands
>> put the repository in a shaky state, where performing certain other
>> operations would be ill advised.  Attempting to start a rebase while a
>> merge conflict is unresolved, for example.  IIRC, git actually tries to
>> stop users from shooting their feet in this way.
>>
>> And so it should be for the stash operation:  If applying a stash yields
>> a conflict, it has to be resolved or aborted before something like a
>> rebase or merge is attempted.
>
> That already happens, and I have no idea how you think this safe-guarding
> has anything to do whether the "--continue" option makes sense in "git
> stash", or only in "git stash pop".
>
>> In the long run, I think there's even the possibility of generic "git
>> continue" and "git abort" commands,
>
> Wrong.
>
> You can call "git cherry-pick" (and "git cherry-pick --continue") while
> running a "git rebase -i".
>
> You can run "git rebase", "git stash", "git cherry-pick" and many other
> commands while running a "git bisect".
>
> You can even run a "git rebase" or a "git cherry-pick" while resolving an
> interrupted "git am".
>
> Many, many examples that make it *impossible* for Git to know *what* you
> want to continue, *what* you want to abort.

Right, I'd missed that.  I agree that a generic "git continue" is nonsense.

		M.

Re: [RFC] stash --continue

[Johannes Schindelin]

Hi Marc,

On Thu, 19 Jan 2017, Marc Branchaud wrote:

> On 2017-01-19 10:49 AM, Johannes Schindelin wrote:
> >
> > On Wed, 18 Jan 2017, Marc Branchaud wrote:
> >
> > > On 2017-01-18 11:34 AM, Johannes Schindelin wrote:
> > > >
> > > > On Wed, 18 Jan 2017, Marc Branchaud wrote:
> > > >
> > > > > On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
> > > > >
> > > > > > On Mon, 16 Jan 2017, Stephan Beyer wrote:
> > > > > >
> > > > > > > a git-newbie-ish co-worker uses git-stash sometimes. Last
> > > > > > > time he used "git stash pop", he got into a merge conflict.
> > > > > > > After he resolved the conflict, he did not know what to do
> > > > > > > to get the repository into the wanted state. In his case, it
> > > > > > > was only "git add <resolved files>" followed by a "git
> > > > > > > reset" and a "git stash drop", but there may be more
> > > > > > > involved cases when your index is not clean before "git
> > > > > > > stash pop" and you want to have your index as before.
> > > > > > >
> > > > > > > This led to the idea to have something like "git stash
> > > > > > > --continue"[1]
> > > > > >
> > > > > > More like "git stash pop --continue". Without the "pop"
> > > > > > command, it does not make too much sense.
> > > > >
> > > > > Why not?  git should be able to remember what stash command
> > > > > created the conflict.  Why should I have to?  Maybe the fire
> > > > > alarm goes off right when I run the stash command, and by the
> > > > > time I get back to it I can't remember which operation I did.
> > > > > It would be nice to be able to tell git to "just finish off (or
> > > > > abort) the stash operation, whatever it was".
> > > >
> > > > That reeks of a big potential for confusion.
> > > >
> > > > Imagine for example a total Git noob who calls `git stash list`,
> > > > scrolls two pages down, then hits `q` by mistake. How would you
> > > > explain to that user that `git stash --continue` does not continue
> > > > showing the list at the third page?
> > >
> > > Sorry, but I have trouble taking that example seriously.  It assumes
> > > such a level of "noobness" that the user doesn't even understand how
> > > standard command output paging works, not just with git but with any
> > > shell command.
> >
> > Yeah, well, I thought you understood what I meant.
> >
> > The example was the best I could come up with quickly, and it only
> > tried to show that there are *other* stash operations that one might
> > perceive to happen at the same time as the "pop" operation, so your
> > flimsical comment "why not continue the latest operation" may very
> > well be ambiguous.
> >
> > And if it is not ambiguous in "stash", it certainly will be in other
> > Git operations. And therefore, having a DWIM in "stash" to allow
> > "--continue" without any specific subcommand, but not having it in
> > other Git commands, is just a very poor user interface design. It is
> > prone to confuse users, which is always a hallmark of a bad user
> > interface.
> 
> Please don't underestimate the power of syntactic consistency in helping
> users achieve their goals.  Having some commands use "git foo
> --continue" while others use "git foo bar --continue" *will* confuse
> people, regardless of how logical the reasons for those differences.

But that ship has already sailed!

By your reasoning, it was a mistake to introduce subcommands such as `git
stash pop` in the first place.

> But in the case of stash, I still don't see the utility in having
> operation-specific continuation.

Stephan already gave one good example where you want it: if `git stash
pop` fails, you may want to continue by *not* dropping the stash via `git
stash apply --continue`.

> Consider the following sequence (as you say, this doesn't work yet, but
> making it work seems reasonable):
> 
> 	git stash pop  # creates some conflicts
> 	git stash apply stash@{4} # creates some other conflicts
> 	# (User resolves the conflicts created by the pop.)
> 	git stash pop --continue

Yes, that would make sense: the `pop` would actually drop the stash entry.

> Given the description of the original proposal (do "git reset; git stash
> drop"), what's the state of the index and the working tree?
> 
> In particular, what has the user gained by continuing just that pop?

That it was completed.

> Another thing to ask is, how common is such a scenario likely to be?

We have millions of users. Even a 0.001% chance of anything happening will
bite users, who will then come back to bite us.

Let's just not go into the "how likely is this" game.

> I suggest that it will be far more common for users to resolve all the
> conflicts and then want to continue all their interrupted stash
> operations.  If so, fussily forcing them to explicitly continue the pop
> and the apply is just a waste.

No, it is not a waste, as we require the user nothing else than to be
precise. Do you want to continue the "stash pop"? Okay, then, call "git
stash pop --continue".

> [... a lot of stuff skipped, as it is basically ignoring my point...]
>
> > But foo *is the operation*! By that reasoning, you should agree that
> > "git stash --continue" is *wrong*!
> 
> No, in the user's mind *stash* is the operation!

How can that be true? In the user's mind, the *stash* operation is
equivalent to the *stash save* operation! Because that is what happens
when you call "git stash" without any further command-line parameters.

At this point I will stop commenting on this issue, as I have said all
that I wanted to say about it, at least once. If I failed to get my points
across so far, I simply won't be understood.

Ciao,
Johannes

Re: [RFC] stash --continue

[Marc Branchaud]

On 2017-01-19 04:30 PM, Johannes Schindelin wrote:
>
> At this point I will stop commenting on this issue, as I have said all
> that I wanted to say about it, at least once. If I failed to get my points
> across so far, I simply won't be understood.

Yes, we're obviously looking at this from completely different perspectives.

Stephan (or whoever) if you decide to do this work, I will be content 
with whichever way you choose to go.

		M.

Re: [RFC] stash --continue

[Johannes Schindelin]

Hi Marc,

On Fri, 20 Jan 2017, Marc Branchaud wrote:

> On 2017-01-19 04:30 PM, Johannes Schindelin wrote:
> >
> > At this point I will stop commenting on this issue, as I have said all
> > that I wanted to say about it, at least once. If I failed to get my
> > points across so far, I simply won't be understood.
> 
> Yes, we're obviously looking at this from completely different
> perspectives.

Yes, but you claim to argue from the users' perspective, while I actually
work with enough users to be really certain that I described their mental
model of what an operation is very accurately.

> Stephan (or whoever) if you decide to do this work, I will be content
> with whichever way you choose to go.

So you only wanted to argue and not actually do anything? Tsk, tsk...

:-)

Ciao,
Johannes

Re: [RFC] stash --continue

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> > More like "git stash pop --continue". Without the "pop" command, it
>> > does not make too much sense.
>> 
>> Why not?  git should be able to remember what stash command created the
>> conflict.  Why should I have to?  Maybe the fire alarm goes off right when I
>> run the stash command, and by the time I get back to it I can't remember
>> which operation I did.  It would be nice to be able to tell git to "just
>> finish off (or abort) the stash operation, whatever it was".
>
> That reeks of a big potential for confusion.

Yup.  I agree everything you said in the message I am responding
to.  Marc's argument will inevitably lead to: It should be
sufficient to say "git --continue", as Git should remember
everything for me.  I do not think we want to go there.

Re: [RFC] stash --continue

[Stephan Beyer]

Hi,

On 01/18/2017 04:41 PM, Marc Branchaud wrote:
> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
>> On Mon, 16 Jan 2017, Stephan Beyer wrote:
>>> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
>>> "git stash pop", he got into a merge conflict. After he resolved the
>>> conflict, he did not know what to do to get the repository into the
>>> wanted state. In his case, it was only "git add <resolved files>"
>>> followed by a "git reset" and a "git stash drop", but there may be more
>>> involved cases when your index is not clean before "git stash pop" and
>>> you want to have your index as before.
>>>
>>> This led to the idea to have something like "git stash --continue"[1]
>>
>> More like "git stash pop --continue". Without the "pop" command, it does
>> not make too much sense.
> 
> Why not?  git should be able to remember what stash command created the
> conflict.  Why should I have to?

Dscho and Junio gave you a git-perspective argument.
I give you a user-perspective one:
What if you did "git stash pop" and ran into an (unexpected) conflict.
You resolve it, and you probably - for some reason - don't want to drop
the stash now, as "git stash --continue" (assuming "pop") would do. So
I'd regard it as a feature if you could now run "git stash apply
--continue" to just finish the job without dropping.

Best
Stephan

PS: I put this idea in my todo priority queue. If somebody else is
interested: I am not going to work at this idea before February.

PPS: Any opinions about the mentioned "backwards-compatibility" issue
that people are then forced to finish their commits with "--continue"
instead of "git reset" or "git commit"?

Re: [RFC] stash --continue

[Johannes Schindelin]

Hi Stephan,

On Wed, 18 Jan 2017, Stephan Beyer wrote:

> PPS: Any opinions about the mentioned "backwards-compatibility" issue
> that people are then forced to finish their commits with "--continue"
> instead of "git reset" or "git commit"?

Maybe you could make it so that "git reset" and "git commit" would still
work as before, and reset the state so that "git stash pop --continue"
could complain that there is nothing to continue?

Similar to how we remove CHERRY_PICK_HEAD during a `git reset --hard`,
maybe?

Ciao,
Johannes

Re: [RFC] stash --continue

[Junio C Hamano]

Stephan Beyer <s-beyer@gmx.net> writes:

> This led to the idea to have something like "git stash --continue"[1]
> that would expect the user to "git add" the resolved files (as "git
> status" suggests) but then leads to the expected result, i.e. the index
> being the same as before the conflict, the stash being dropped (if "pop"
> was used instead of "apply"), etc.
>
> Likewise, some "git stash --abort"[2] might be useful in case you did
> "git stash pop" with the wrong stash in mind.
>
> What do you think about that?

"git stash pop --continue" (and "git stash apply --continue") would
make quite a lot of sense.  I like it very much primarily because it
will give us an opportunity to correct a major UI glitches around
applying stashed changes to the working tree.

Don't people find it strange that "stash pop" that applies cleanly
would not touch the index, leaving (an equivalent of) the changes
stashed earlier floating in the working tree, but "stash pop" that
conflicts and needs a three-way merge touches the index and the
usual way of concluding the manual conflict resolution is "git add"
the paths, meaning that the changes that were not ready hence
floating in the working tree back when the stash was made goes into
the index when the user concludes "stash pop"?

With an explicit "--continue", we can fix that so that we reset the
index to the HEAD.  That way, whether the changes have conflict with
the HEAD's tree or not, the end user after "stash pop" will see the
changes in the working tree and "git diff" (no HEAD argument or
"--cached" option) will consistently show what came from the stash.