Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> writes: > >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >>> Junio C Hamano <gitster@xxxxxxxxx> 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". ... >>> >> >> [...] >> >>> 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. >> >> Redundant? Yes. Unnecessary? Yes. Useful? Yes. ;-) >> >> I took the steps to propose the new feature after yet another round of >> "how do I quickly store this tiny bit of changes I just figured I need >> for later, out of bunch of VIWIP changes?" >> >> git stash --staged >> >> is exactly the (currently missing) answer for me, as I have pretty >> interactive tool to stage diff chunks always handy. >> >> What's your answer, I wonder? > > I am the one who questions the usefulness of "stash --staged" and > thinks "add -p", "stash -k", test, "commit" is a much better way to > solve the "we have a messy working tree and we want to create a > clean multi-step end result out of it" problem I don't want to create a multi-step result out of it, if it means a series of commits. The question is about a change that is *unrelated* to the series I'm supposedly doing. > > I consider "stash --staged" as a solution in search of a problem, so > you'd need to ask somebody else for a problem that "stash --staged" > is suitable for. I didn't ask you what --staged is suitable for, sorry. I asked how do you solve the problem of saving an *entirely unrelated* subset of changes for future use? If the answer is "I don't have such problem", it's OK with me, but my point is that I, and at least a few others, seem to have such a problem frequently enough to justify introduction of the --staged option. > > And "I want to stash away this tiny bit" is better solved by *not* > doing "git add" it to the index and then stashing. Rather, I'd just > do "commit" so that I can "rebase -i" to reorganize these bits > later. Of course, to test the "tiny bit" standalone, I may use > "stash -k" first, but do not see such a senario shows the merit of > using "stash --staged" over other tools. That is a good solution for *different* problem. The changes I want to stash-out supposedly don't belong to the series of changes currently being worked on *at all*, and I don't want to test them right now as I'm working on entirely unrelated set of problems and don't want to get side-tracked. So, the analog here is not using "stage -k"->test->commit cycle, it's rather temporary switching to another branch and committing there, like this: <hack, hack, hack...> <notice unrelated problem, give it a quick fix and stage it> $ git checkout -b tmp-fix-bla-bla $ git commit -m "Will have to look at bla-bla later" $ git checkout - <hack continues, probably using stash -k and rebasing as needed> <... time passes... > $ git switch some-branch $ git cherry-pick -n tmp-fix-bla-bla <... continue to work on the bla-bla fix ...> See? But now, we already have such a wonderful place for temporary states called "stash". Why should it be so hard to "commit" right to the stash instead of stomping around and then house-keeping of these temporary non-branches? That's what "stash --staged" is suitable for, not for creating clean sequence of commits out of a mess, where "stash -k" indeed shines. > >> That said, I'm also curious what story, if any, do you have for 'git >> stash --patch', as exactly the same story should be applicable to >> proposed 'git stash --staged', as far as I can see. > > "stash --patch" is also "Meh" from my point of view. I do not > strongly object to its existence, it may be a OK tool for a small > scale use, but I suspect it would be more frustrating than helpful > to users when applied in a larger workflow story, just like I view > "git stash --staged". I see, thank you for clarification. Thanks, -- Sergey Organov
