Re: [PATCH RFC v1] stash: implement '--staged' option for 'push' and 'save'

[Junio C Hamano <gitster@pobox.com>]

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

> More importantly...
>
> Whenever I think about a new "feature", I try to come up with a
> story in which the feature effectively improves the end-user's life,
> how it fits in the larger picture, and enables something that is
> hard to do by combining other tools.
>
> The kind of "story" I would aim for is like this.  Suppose we were
> selling not "git stash -S" but "git stash -k". ...

To answer my previous "question", I guess this is usable in the same
scenario where "git stash -k" is useful.  After creating a bunch of
stash entries created by "git stash -S", if you want to test any of
them (because what is in these stash entries did not exist without
other working tree changes, and couldn't have been tested in the
working tree standalone by definition), you can "git stash pop" such
a stash entry created by "git stash -S" and then "git stash -k" to
materialize what was in the stash alone in the working tree to test
_later_ (as opposed to testing _first_; in the "git stash -k"
workflow, you'd collect "good bits" in the index with "add -p"
first, then "clear the remaining cruft" with "git stash -k" to test
it first, and take the cruft back with "git stash pop").

So in short, I do not think I am strongly opposed to "git stash -S"
existing, since I did find one use case story that it could be used,
but I do think it is redundant and unnecessary.

IOW, "git stash -k" followed by "git stash" and "git stash pop" the
one created with "git stash -k" would be an equivalent operation to
this new "git stash -S".  But the price of being able to combine
these three operations into one is that the user cannot have the
state after "stash -k" in the working tree to inspect, and I cannot
shake the feeling that this new "feature" is like a tail wagging a
dog.  If the "goal" is to "create a stash entry out of what is in
the index", then "stash -S" is a one-step handy tool that directly
achieves that "goal", but that "goal" does not smell like a useful
"goal" in the first place.  To "create a commit by sifting mixed
changes in the working tree with 'add -p' and then gaining a chance
to do a clean and final testing" would be the "goal" of "stash -k",
and that I can see a clear benefit.  Contrasting to that, I am not
so sure about "stash -S".  It would be another way to eventually do
the same thing but along a more roundabout route.

So, I dunno.