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?
