mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Philip Oakley <>
To: Junio C Hamano <>, Duy Nguyen <>
Cc: Poughon Victor <>,
	"" <>
Subject: Re: Feedback on git-restore
Date: Thu, 16 May 2019 13:12:14 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 16/05/2019 03:18, Junio C Hamano wrote:
> Duy Nguyen <> 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.
I would agree.

"the Index" is grossly under-documented and explained. I still don't 
have a proper understanding of all the multiple Nuances regarding the 
Index concept. Only a moment ago I was reading a thread that talked 
about having multiple indexes and the wrong one being referenced or locked.

I tend to map the Index to an old-fashioned 'out-box' on the corner of 
one's desk (from the days when everything was paper and cc really meant 
a carbon copy made with carbon paper). One would work on a document and 
when 'finished' place it in the out-box, which also acted as a 
work-in-progress (wip) box. Only later would a secretary/mail-person 
come around to see what needed filing/sending.

The fact that there can be many indexes, with multiple stages (all 
un-named) is a further source of confusion. For the average user, the 
only visible artefacts are those in the file system, and perhaps the 
crisp memory of the last commit. So I can see where Victor is coming 
from. I don't think we should be solely relying on the experience of 
user mistakes for their learning.

Maybe we need a `git index` command to make it far more visible to 
average users (or `git staging-area --show`, with a --cached option ;-).
>> 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.
If the Index is central it need to be to get out from behind the 
curtain. Just sayin'.


  reply	other threads:[~2019-05-16 12:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15  9:38 Feedback on git-restore Poughon Victor
2019-05-15 10:30 ` Duy Nguyen
2019-05-15 10:59   ` Ævar Arnfjörð Bjarmason
2019-05-15 11:16     ` Duy Nguyen
2019-05-16  2:18   ` Junio C Hamano
2019-05-16 12:12     ` Philip Oakley [this message]
2019-05-16 12:44       ` Duy Nguyen
2019-05-18 14:19         ` Philip Oakley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).