From: Phillip Wood <phillip.wood123@gmail•com>
To: "D. Ben Knoble" <ben.knoble@gmail•com>
Cc: phillip.wood@dunelm•org.uk, Junio C Hamano <gitster@pobox•com>,
"J. Dettweiler" <git.vger.kernel.org@dettweb•de>,
git@vger•kernel.org
Subject: Re: [FEATURE] Proposal: git stash --only-unstaged
Date: Tue, 16 Sep 2025 12:03:11 +0100 [thread overview]
Message-ID: <4b689f92-5277-4e57-b4b7-8cc241ddd664@gmail.com> (raw)
In-Reply-To: <CALnO6CCsFuYqo-q8D1g=vR9q22+Cy1MAgk1Ld0cD1wFNjr-eSw@mail.gmail.com>
Hi Ben
On 29/08/2025 14:30, D. Ben Knoble wrote:
> On Fri, Aug 29, 2025 at 9:06 AM Phillip Wood <phillip.wood123@gmail•com> wrote:
>>
>> I think the example works but may generate conflicts when the stash is
>> popped. One can argue that the conflicts are unnecessary because they
>> could be avoided by popping the unstaged changes but I don't think the
>> example is broken as such.
>
> Thanks, let me try to rephrase: the example makes no mention of
> conflicts appearing or having to adjust them. It seems to heavily
> imply to me that no such conflicts are expected, though as we
> discussed upthread it seems unlikely you _won't_ get conflicts if you
> do
Yes, I think if you edit any staged changes (that is the lines that
differed between the index and HEAD when "git stash" was run) you'll end
up with conflicts. If you edit a line where the index, HEAD and the
worktree matched when the stash was created then I don't think you will
see a conflict. Overall conflicts seem pretty likely, so maybe we should
mention them in the documentation.
> [...]
> I suppose my main complaint is nothing about the example makes it
> clear that's the intended use case to me? Hence
> - we could change the example to mention conflicts and/or use case
> (smaller patch, punts on the problem)
> - we could change the code to accommodate the example as written
> (using ideas from your script; harder but bigger win IMO?)
I was hoping that we'd hear back from J. Dettweiler as to whether the
ideas in the script were useful. It would certainly be better to update
the command to avoid conflicts if we can.
Thanks
Phillip
next prev parent reply other threads:[~2025-09-16 11:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 8:51 [FEATURE] Proposal: git stash --only-unstaged J. Dettweiler
2025-08-13 15:30 ` Junio C Hamano
2025-08-13 17:02 ` D. Ben Knoble
2025-08-16 16:12 ` Phillip Wood
2025-08-17 16:08 ` Junio C Hamano
2025-08-18 15:14 ` Phillip Wood
2025-08-18 23:41 ` Ben Knoble
2025-08-29 13:06 ` Phillip Wood
2025-08-29 13:30 ` D. Ben Knoble
2025-09-16 11:03 ` Phillip Wood [this message]
2025-09-16 17:10 ` D. Ben Knoble
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=4b689f92-5277-4e57-b4b7-8cc241ddd664@gmail.com \
--to=phillip.wood123@gmail$(echo .)com \
--cc=ben.knoble@gmail$(echo .)com \
--cc=git.vger.kernel.org@dettweb$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=phillip.wood@dunelm$(echo .)org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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