From: Philip Oakley <email@example.com>
To: Duy Nguyen <firstname.lastname@example.org>
Cc: Junio C Hamano <email@example.com>,
Poughon Victor <Victor.Poughon@cnes.fr>,
Subject: Re: Feedback on git-restore
Date: Sat, 18 May 2019 15:19:58 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 16/05/2019 13:44, Duy Nguyen wrote:
> On Thu, May 16, 2019 at 7:12 PM Philip Oakley <email@example.com> wrote:
>> 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 ;-).
> Not commenting on the other parts (and also Junio's mail) since I
> still need more time to process.
> But how about we see the index as a "commit-in-progress" (or "staging
> area" which is almost the same, maybe "commit area" is better)?
My initial comment was more about the cognitive disconnect between
Victor's original reply where he has the commit and the file system as
the (only) firm reference points, and then your reply, which makes the
case that the _Index_ is central.
It was that disconnect that I wanted to highlight, which is at a level
above the discussion on just the restore command.
There was a lot of discussion a year or three back about the terminology
of cache/Index/staging for this middle area. It probably wasn't resolved
fully as it only discussed the name, rather than why the concept wasn't
well understood, and what was needed to fix _that_.
> You can't make a commit visible unless you check it out (and then can
> use various tools available to work on filesystem), or you use git
> diff/show to examine it. The index is treated pretty much the same
> way, except that it does not have a proper SHA-1 yet because it's
> still a work in progress.
I'd say most users feel happy about the fixedness of their last commit,
and probably feel happy with the ability to view it via various tools
(especially if pushed to their GitHub/Lab/Bucket repo). The apparently
transient nature of the index is part of its Achilles heel. We talk too
easily about 'blowing it away' . Such phrases reinforce the user
belief that they should treat it as a bit of a swamp area.
We don't have an index_log of the changes to the staging tree, as files
are added or removed. That view implies that the index is simply the
current work-in-progress (wip) tree, and doesn't contain anything else..
> Short of creating a fuse filesystem to show you the index content (as
> read-only files) I don't see any better way that you can actually see
> the index without checking it out.
Surely? the 'git status' command  is, in a way, trying to be that
view, but we just haven't told the users
> PS. Yes I ignored the role of the index during a merge conflict. Not
> relying on the index for conflict handling might be possible, but I'm
> not going to touch that topic, way out of my area.
The role during merges would be part of that missing conceptual
structure. Our documentation is doing a little too much of the 'ignore
what's behind the curtain' . I've certainly fallen for that often.
The need for various web explanations e.g. [3,4] also suggest we could
be more assertive in our top level user documentation about 'index is
one of the most important data structures in git'.
In summary, I think the problem that Victor alludes to is at a higher
level with respect to how we document what the staging area / index is
 e.g. https://shafiul.github.io//gitbook/1_the_git_index.html
 Wizard of Oz, Powerful concept, vs loose tools.
prev parent reply other threads:[~2019-05-18 14:20 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
2019-05-16 12:44 ` Duy Nguyen
2019-05-18 14:19 ` Philip Oakley [this message]
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).