Re: [PATCH 3/3] stash: fix stash application in sparse-checkouts

[Chris Torek <chris.torek@gmail.com>]

On Fri, Nov 20, 2020 at 8:56 AM Elijah Newren via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> branch.  However, this simplistic view doesn't quite work in practice,
> because stash tweaks it a bit due to two factors: (1) flags like
> --keep-index and --include-untracked (why we used two different verbs,
> 'keep' and 'include', is a rant for another day)

:-)

Not that this should affect any of these changes, but I'd also note
that the fact that using `-u` or  `-a` makes a third commit that cannot
be ignored later is a problem as well.  (`git stash list` should probably
annotate the listed stashes as to whether they are two- or three-commit
stashes.)

> stash has traditionally gotten this special behavior by first doing a
> merge, and then when it's clean, applying a pipeline of commands to
> modify the result.  This series of commands for
> unstaging-non-newly-added-files came from the following commands:
>
>     git diff-index --cached --name-only --diff-filter=A $CTREE >"$a"
>     git read-tree --reset $CTREE
>     git update-index --add --stdin <"$a"
>     rm -f "$a"
>
> You might that between the merge that proceeded these commands and these

s/might/might think/, perhaps?  And, s/proceeded/preceded/, probably.

(I didn't look closely at the rest of this but the idea seems sound.)

Chris