From: Junio C Hamano <firstname.lastname@example.org>
To: Duy Nguyen <email@example.com>
Cc: Poughon Victor <Victor.Poughon@cnes.fr>,
Subject: Re: Feedback on git-restore
Date: Thu, 16 May 2019 11:18:36 +0900 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <20190515103031.GA29149@ash> (Duy Nguyen's message of "Wed, 15 May 2019 17:30:31 +0700")
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.
> 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.
next prev parent reply other threads:[~2019-05-16 2:19 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 [this message]
2019-05-16 12:12 ` Philip Oakley
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).