public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
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


  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