On Wed, Dec 12, 2018 at 2:23 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote: > > On Tue, Dec 11, 2018 at 7:12 AM Elijah Newren <newren@xxxxxxxxx> wrote: > > > > On Mon, Dec 10, 2018 at 7:13 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > > > Duy Nguyen <pclouds@xxxxxxxxx> writes: > > > > > > > Elijah wanted another mode (and I agree) that modifies worktree but > > > > leaves the index alone. This is most useful (or least confusing) when > > > > used with <tree-ish> and would be default in restore-files. I'm not > > > > saying you have to implement it, but how do the new command line > > > > options are designed to make sense? > > > > > > I'd model it after "git apply", i.e. > > > > > > git restore-files [--tree=<treeish>] <pathspec> > > > > > > would work only on the working tree files, > > > > > > git restore-files --tree=<treeish> --cached <pathspec> > > > > > > would match the entries in the index that match pathspec to the > > > given treeish without touching the working tree, and > > > > > > git restore-files --tree=<treeish> --index <pathspec> > > > > > > would be both. > > > > > > I have never been happy with the phraso, the (arbitrary) distinction > > > between --cached/--index we use, so in the very longer term (like, > > > introducing synonym at 3.0 boundary and deprecating older ones at > > > 4.0 boundary), it may not be a bad idea to rename "--index" to > > > "--index-and-working-tree" and "--cached" to "--index-only". > > > > > > But until that happens, it would be better to use these two > > > consistently. > > > > I agree that consistency is important, but trying to distinguish > > between "--cached" and "--index" is _extremely_ painful. I still > > can't keep the distinction straight and have to look it up every time > > I want to use either. I don't know how to possibly teach users the > > meaning. Could we introduce synonyms earlier at least, and make the > > synonyms more prominent than the "--cached" and "--index" terms in the > > documentation? > > For git-checkout I think --index and --cached fit. For restore-files, > if you come up with better names, I'll gladly use that. Otherwise I'll > just use these. I've changed my mind. I'm not using --index and --cached for "git restore" (formerly "git restore-files"). So how about this? git restore --from=<tree> <pathspec> will update both the index and worktree. git restore --from=<tree> --keep-index <pathspec> will not update the index git restore --from=<tree> --keep-worktree <pathspec> will not update worktree And I'm thinking of adding these to "git reset" too. It will have the forth form: git reset [--keep-index] [--keep-worktree] [--keep-nothing] [<commit>] which is similar to --soft, --mixed and --hard, but with better names: --soft is --keep-worktree and --keep-index, --mixed is --keep-worktree and --hard is --keep-nothing (i.e. the only change is HEAD). Although, if I work it out, I might just ignore "git reset" and make sure "git switch" and "git restore" can do whatever "git reset" can then remove its "common command" status. This part is more thinking out loud, but "git switch" can have a new form git switch --reset-branch [--keep-worktree] [--keep-index] <start-point> which resets "HEAD" (and switch of course) but do not enter detached mode. This covers a common use case of "git reset [options] <commit>". Then either "git restore" learns about "--abort-in-progress" to abort cherry-pick/merge/revert, or those commands have a new --abort and --quit option... -- Duy
