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. -- Duy
