git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Eric Sunshine" <sunshine@sunshineco.com>,
	"Git List" <git@vger.kernel.org>,
	"Thomas Rast" <tr@thomasrast.ch>,
	"Denton Liu" <liu.denton@gmail.com>
Subject: Re: [PATCH RFC v1] stash: implement '--staged' option for 'push' and 'save'
Date: Tue, 12 Oct 2021 21:25:52 +0300	[thread overview]
Message-ID: <87lf2yqevj.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqzgre40ff.fsf@gitster.g> (Junio C. Hamano's message of "Tue, 12 Oct 2021 10:28:52 -0700")

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

> Sergey Organov <sorganov@gmail.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> 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". ...
>>>
>>
>> [...]
>>
>>> 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

  reply	other threads:[~2021-10-12 18:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-01 22:12 [PATCH RFC] stash: implement '--staged' option for 'push' and 'save' Sergey Organov
2021-10-11 20:16 ` [PATCH RFC v1] " Sergey Organov
2021-10-11 21:21   ` Eric Sunshine
2021-10-11 21:55     ` Sergey Organov
2021-10-12  9:18       ` Ævar Arnfjörð Bjarmason
2021-10-12 11:20         ` Sergey Organov
2021-10-12 12:04         ` Junio C Hamano
2021-10-12 12:34           ` Junio C Hamano
2021-10-12 16:07             ` Sergey Organov
2021-10-12 17:28               ` Junio C Hamano
2021-10-12 18:25                 ` Sergey Organov [this message]
2021-10-13  4:48                   ` Junio C Hamano
2021-10-13 13:43                     ` Sergey Organov
2021-10-15 15:04   ` [PATCH v2] " Sergey Organov
2021-10-15 17:58     ` Junio C Hamano
2021-10-15 19:05       ` Sergey Organov
2021-10-15 19:22         ` Junio C Hamano
2021-10-15 20:14           ` Sergey Organov
2021-10-15 20:21             ` Sergey Organov
2021-10-18 16:09     ` [PATCH v3] " Sergey Organov
2021-10-26  5:05       ` Jeff King
2021-10-27 15:11         ` Sergey Organov
2021-10-27 15:20       ` [PATCH v4] " Sergey Organov
2021-10-27 21:19         ` Junio C Hamano
2021-10-28  8:29           ` [PATCH] stash: get rid of unused argument in stash_staged() Sergey Organov
2021-10-28 21:17             ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lf2yqevj.fsf@osv.gnss.ru \
    --to=sorganov@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=liu.denton@gmail.com \
    --cc=sunshine@sunshineco.com \
    --cc=tr@thomasrast.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).