From: Junio C Hamano <gitster@pobox.com>
To: Ricardo C <rpc01234@gmail.com>
Cc: Phillip Wood <phillip.wood123@gmail.com>,
phillip.wood@dunelm.org.uk, git@vger.kernel.org
Subject: Re: [PATCH] builtin/stash: configs keepIndex, includeUntracked
Date: Wed, 21 Feb 2024 15:53:59 -0800 [thread overview]
Message-ID: <xmqqzfvtjrvs.fsf@gitster.g> (raw)
In-Reply-To: <xmqq4je1o9yu.fsf@gitster.g> (Junio C. Hamano's message of "Wed, 21 Feb 2024 12:09:45 -0800")
Junio C Hamano <gitster@pobox.com> writes:
> Ricardo C <rpc01234@gmail.com> writes:
>
>> Permanently enabling keepIndex is mainly intended for people that like
>> to stash their unstaged changes before committing (e.g., for testing
>> them independently of other changes). The main issue with what you
>> recommend is that, if they forget to use `-k`, then the entire state
>> of the index is lost, which is especially problematic if the changes
>> were interactively staged.
>
> Doesn't "git stash pop --index" meant to recover from such a
> mistake, though? If you stash, because your "git commit" notices
> there is no change after you did "git stash" without "-k", your
> recovery to "pop --index" would apply the changes to the index and
> to the working tree on top of exactly the same commit, so there is
> no risk of losing any changes by doing so, right? IOW, such a pop
> will always round-trip.
Actually, "git commit" gets into the picture of making and
recovering from such a mistake a bit more costly than I made it
sound in the above. My bad.
The common sequence is
$ edit edit edit
$ git add -p
$ git stash -k
$ build what is in the index and test
and then when you are happy, conclude it with
$ git commit [NO -o/-i/pathspec]
followed by
$ git stash pop
to continue for the next commit. So "git commit" should notice if
your earlier "stash -k" forgot to say "-k", but by that time, you
would have wasted the whole build and test cycle. The HEAD wouldn't
have moved, so the conclusion that "pop --index" would be a good way
to recover from "stash" without "--keep" does not change, though.
next prev parent reply other threads:[~2024-02-21 23:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-18 3:30 [PATCH] builtin/stash: configs keepIndex, includeUntracked MithicSpirit
2024-02-18 10:32 ` Phillip Wood
2024-02-18 17:54 ` Ricardo C
2024-02-20 11:01 ` Phillip Wood
2024-02-20 17:47 ` Junio C Hamano
2024-02-21 19:13 ` Ricardo C
2024-02-21 20:09 ` Junio C Hamano
2024-02-21 23:14 ` Ricardo C
2024-02-21 23:53 ` Junio C Hamano [this message]
2024-02-20 2:52 ` Junio C Hamano
2024-02-20 3:30 ` Ricardo C
2024-02-20 3:44 ` Junio C Hamano
2024-02-20 3:59 ` Ricardo C
2024-02-20 19:30 ` Kristoffer Haugsbakk
2024-02-19 8:04 ` Jean-Noël Avila
2024-02-19 21:41 ` Ricardo C
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqzfvtjrvs.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=phillip.wood123@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=rpc01234@gmail.com \
/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.
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 NNTP newsgroup(s).