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

From: Chris Torek <chris.torek@gmail.com>
Date: Nov 21, 2020, 12:47 UTC
Message-ID: <CAPx1GvfaZ-pRznnOQELBYQ7LCk-sr_-Rd0aPcJ6ghM5yt8LpnA@mail.gmail.com>
In-Reply-To: <5143cba7047d25137b3d7f8c7811a875c1931aee.1605891222.git.gitgitgadget@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.)

Show 11 quoted lines

> 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