Re: Feedback on git-restore

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> I think it depends on whether use actively use the index, or you
>> mostly ignore it and always do "git commit -a" and friends.
>>
>> When you do use the index, the "worktree <-> index <-> HEAD" is the
>> three stages that you are aware, in that order, and restoring from the
>> "next" stage is expected.
>>
>> It does feel natural for me that we "restore worktree from the index"
>> and "restore index from HEAD". But maybe I'm just too used to the old
>> way of thinking? Let's see what other people say.
> I am somewhat sympathetic to unexperienced users who do not "get"
> Git here, but because I still think you cannot make effective use of
> Git without understanding the workflow using the index as an "extra"
> level sitting between the working tree and the commits, I think it
> is a learning experience worth investing in for a new user to get
> used to the way of thinking you showed in the above paragraphs.

>> This is also consistent with other commands, for example "git diff
>> --staged/--cached" compares the index and HEAD and "git diff" compares
>> worktree and the index. You would need extra effort e.g. "git diff
>> HEAD" to compare the worktree and HEAD.
> Exactly.
>
>> This --index vs --staged was discussed and --staged is a compromise.
>> The problem is --index means something different in existing
>> commands. It specifies that you want to target both the index _and_
>> worktree. --cached on the other hand only targets the index [1].
>>
>> It's confusing, yes. But --index/--cached is part of Git and we cannot
>> just ignore our baggage and redefine --index to "just index".
> Another thing worth pointing out here may be that a user would stop
> feeling it a baggage once the index-centric way of thinking sinks
> in.  Because the index is so central to the local use of Git
> workflow (i.e. "I am just cloning and pulling from the outside world
> to fllow along" does not count), "just the working tree and not the
> index" mode is an anomaly, until/unless you start talking about
> going backwards (e.g. "I've smudged my working tree by mistake, and
> need to recover by copying something out to it", which is the mental
> model of "restore").
>
> 	Side note: while at the mechanical level what it does is an
> 	equivalent to what "checkout -- <paths>" does, the mental
> 	models are different.  "checkout" is still a way to move
> 	forward "I need the contents of these paths in my next
> 	commit to look like those in that tree-ish, so copy them out
> 	to the working tree (to e.g. compile test) and also to the
> 	index (for e.g. the ease of committing after testing is
> 	done)".
>
>> So the compromise is we leave --index/--cached alone and gradually
>> move to the --staged/--worktree combo (for other commands as well).
> I think what is truly new and valuable is the "working tree only,
> bypassing the index" mode, but I am not sure if we want to always
> force us to say both when we want to affect both the index and the
> working tree, as the index is still central to the local workflow.
> I am not sure if there is a wide agreement with such a "gradually
> move to" plan.
>
> Also, when you want to only affect the indexed contents, wouldn't
> existing "--cached" suffice?
>
> IOW, I do not mind --staged as a synonym for --cached, and --worktree
> as a useful addition, but I do not think these new pair should replace
> the existing ones.