Duy Nguyen <pclouds@xxxxxxxxx> writes:
> On Sat, Feb 2, 2019 at 12:57 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>
>> Duy Nguyen <pclouds@xxxxxxxxx> writes:
>>
>> > Of course we could just do --index and --worktree, each option
>> > restores the respective part. Then it's combinable (and extensible in
>> > the future). But then "git restore" means "git restore --index
>> > --worktree" and typing "git restore --index" effectively removes the
>> > default "--worktree", which seems a bit twisted.
>>
>> Or "git restore --no-worktree" (essentially, instead of saying
>> "keep", say "no" to mean "negation").
>>
>> Incidentally, "git restore --no-index" does not have a counterpart
>> in "git checkout", but I think it is probably a good thing to add;
>> as it has to do far more than "git cat-file blob $tree:$path >$path"
>> these days.
>
> OK this hopefully will be the final design
>
> (git restore) "[--worktree] <paths>" restores worktree paths from index
>
> "--index <paths>" restores the index from HEAD (aka "git reset")
>
> "--source <tree> (--index|--worktree) <paths>" restores index or
> worktree (or both) from <tree>
>
> I'm a bit reluctant to support "git restore --index --worktree
> <paths>" without --source, which should default to HEAD, since it's a
> bit unclear/inconsistent ("git restore --worktree <paths>" defaults to
> index as the source, but here we use a different default source).
Ok, so we grab things from the index by default, but with --source
<tree>, we can tell the command to grab things from the tree. When
we are explicitly told to update the index with "--index", it would
be nonsense to grab things from the index, so "--source <tree>"
becomes required in that case. Makes sense.
To summerize and full enumerate all the allowed variants:
* --index --worktree --source <tree> <path>...
Update both from a tree; --source <tree> is required.
* --index --no-worktree --source <tree> <path>...
Update only the index but not the working tree; --source <tree>
is required.
* --no-index --worktree <path>...
Update only the working tree files without touching the index
(new feature that cannot be done with the current Git, although
"cat-file -p >path" may be close enough at times), from the index
* --no-index --worktree --source <tree> <path>...
Update only the working tree files without touching the index
from a tree-ish.
* --no-index --no-worktree <path>...
Update nothing, which is a no-op that is not all that useful.
* --no-index --no-worktree --source <tree> <path>...
Update nothing, which is a no-op that is not all that useful.
I am getting the impression that to save typing, you would want to
make "--index --worktree" the default (i.e. among the above, only
--no-index and --no-worktree need to be spelled explicitly), but
there is one glitch. Updating from the index must be spelled
explicitly with "--no-index --worktree".
So perhaps the defaulting rule for the "--index" option must become
a bit more tricky. Perhaps the rules are:
* --worktree is the defeault; --no-worktree can be given from the
command line to countermand it, and --worktree can be given from
the command line to be more explicit.
* when --source <tree> is given from the command line, --index is
the default, and --no-index can be given to countermand it.
* when --source <tree> is not given from the command line,
--no-index is the only sensible choice. It can be given from the
command line to be more explicit, but giving --index to
countermand the --no-index default would be an error, as updating
the index, whether the same update also goes to the working tree,
must come from a --source <tree>.
Am I following you correctly?
Thanks.
