On Fri, Aug 29, 2025 at 9:06 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote:
>
> Hi Ben
>
> On 19/08/2025 00:41, Ben Knoble wrote:
> >
> >> Le 18 août 2025 à 11:14, Phillip Wood <phillip.wood123@xxxxxxxxx> a écrit :
> >>
> >> On 17/08/2025 17:08, Junio C Hamano wrote:
> >>> Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
> >>>> To use it create your stash with "git stash push --keep-index" and then
> >>>> use the script to pop the unstaged changes rather than using "git stash
> >>>> pop". If the script proves to be useful then perhaps we could add an
> >>>> "--unstaged" option to "git stash pop"
> >>> Hmph, would the behaviour useful enough that it should be always
> >>> enabled, without any new option? I strongly suspect that those who
> >>> worked on adding "--keep-index" option did not expect the user to be
> >>> mucking with the working tree files while "testing the staged stuff
> >>> by updating the working tree files to match it and nothing else",
> >>> and as long as the end-user stays within that originally designed
> >>> use case, nothing changes for them, no?
> >
> > I can’t particularly comment on the script, but I do think the example
> > in the docs should either just work or be adjusted to work.
>
> 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
# ... hack hack hack ...
$ git add --patch foo # add just first part
to the index
$ git stash push --keep-index # save all other
changes to the stash
$ edit/build/test first part
$ git commit -m 'First part' # commit fully tested change
$ git stash pop # prepare to work on
all other changes
# ... repeat above five steps until one commit remains ...
$ edit/build/test remaining parts
$ git commit foo -m 'Remaining parts'
since we explicitly say "edit[…] first part," since it seems natural
to me for that to include editing "foo." Perhaps this is where Junio's
suspicion (reproduced below) falls afoul of the language used in the
example?
> I strongly suspect that those who
> worked on adding "--keep-index" option did not expect the user to be
> mucking with the working tree files while "testing the staged stuff
> by updating the working tree files to match it and nothing else",
> and as long as the end-user stays within that originally designed
> use case, nothing changes for them, no?
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?)
> >> Yes it probably would make sense if we knew that the stash had been
> >> created with "--keep-index". At the moment I don't think there is
> >> anywhere to tell from looking at the stash if that's the case but we
> >> could add a trailer to the commit message when we create the stash to
> >> record that it was created with "--keep-index" and apply only the
> >> unstaged changes when we see that trailer.>
> > This seems reasonable; I wonder if there would be any interaction
> > with the stash import/export features? But perhaps those omitted the
> > index anyway, I cannot recall.
>
> It exports the stash commits as-is so it should be fine I think
Great!
> Thanks
>
> Phillip
Thank _you_ for taking a look and providing something to work from :)
--
D. Ben Knoble
