On Sat, Nov 21, 2020 at 4:47 AM Chris Torek <chris.torek@xxxxxxxxx> wrote: > > 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.) Yeah, it seems a bit odd when you compare to saving and applying cached changes; for that, stash requires you to specify BOTH --keep-index to to push/save, AND --index to pop/apply. However, for saving and applying untracked or ignored changes, you merely need to record them at push/save time and they automatically always apply. Not very consistent. (But, again, unrelated to these patches, so this is mostly just recreational complaining at this point. I'm not planning to tackle these bits.) > > 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. Indeed; thanks for catching those. I will fix them up. > (I didn't look closely at the rest of this but the idea seems sound.) > > Chris
