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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 12, 2021, 12:34 UTC
Message-ID: <xmqqo87u777d.fsf@gitster.g>
In-Reply-To: <xmqqa6je8n5c.fsf@gitster.g>

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

Show 9 quoted lines

> 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.