On Fri, Nov 20, 2020 at 8:56 AM Elijah Newren via GitGitGadget <gitgitgadget@xxxxxxxxx> 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
