From: Philip Oakley <email@example.com>
To: Junio C Hamano <firstname.lastname@example.org>, Duy Nguyen <email@example.com>
Cc: Poughon Victor <Victor.Poughon@cnes.fr>,
Subject: Re: Feedback on git-restore
Date: Thu, 16 May 2019 13:12:14 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 16/05/2019 03:18, Junio C Hamano wrote:
> Duy Nguyen <email@example.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.
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.
>> 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 .
>> 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
>> 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'.
next prev parent 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
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: http://vger.kernel.org/majordomo-info.html
* 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).