Re: [PATCH 6/8] checkout: add --cached option

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 11, 2018, 03:13 UTC
Message-ID: <xmqqva40lps2.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CACsJy8CfgJ4NAnbMjBFGhRWscZxJCgxtx0QwSMw7MTjeMT4gDw@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 5 quoted lines

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