From: Andy Whitcroft <apw@shadowen.org>
To: t2a2e9z8ncbs9qg@brefemail.com
Cc: git@vger.kernel.org
Subject: Re: "stage files" vs "cached files"
Date: Thu, 19 Oct 2006 16:58:52 +0100 [thread overview]
Message-ID: <4537A0BC.5040301@shadowen.org> (raw)
In-Reply-To: <eh7vl2$unr$1@sea.gmane.org>
Jerome Lovy wrote:
> Hi,
>
> after having read tutorial1+2, I thought the following were more or less
> synonyms: index ~ directory cache ~ staging area
>
> But then I discover that --cache and --staged are two different things,
> notably when using ls-files.
>
> The documentation states indeed:
> "--cached Show cached files in the output"
> "--stage Show stage files in the output"
>
> I'm a bit confused. Is maybe a "stage file" entry missing in the glossary?
>
> TIA for clarification/pointer.
> Jérôme
This is not stage as in staging area, its stage as in 'at a cirtain
stage'. It refers to files which are in the index but are in conflict.
The cache doesn't just contain an entry for each file. It contains an
entry for each file version in a merge situation. These are referred to
as 'stages'. There is a description in the documentation about how they
get pushed 'down' to stage 0 and then are deemed merged (see
Documentation/core-tutorial.txt).
Below is the git ls-files --cached, and --stage output from a repo which
has one file 'bar' which is fine and another 'bar' which has a conflict.
apw@pinky$ git ls-files --cached
bar
this
this
this
apw@pinky$ git ls-files --stage
100644 8dc5f23c673e9c1ac8dd3499f9acab11b093527f 0 bar
100644 01e79c32a8c99c557f0757da7cb6d65b3414466d 1 this
100644 fbbafbfdaadbff9c7f8db580f91a8ab5a0653704 2 this
100644 10c8337d3d240283bdf35af68d17d1319ca069a4 3 this
Note that there is in fact three 'this's in the index. The first entry
is bar which is in stage 0 and is merged fine. 'this' however appears
three times. 1 represents the common parent of the merge (I believe)
and 2 and 3 represent the conflicting options for that. The 'this' on
disk has the mangled version with both sets of changes in, but this
information can be used to show the actual files in the various forms.
apw@pinky$ git cat-file blob :1:this
1
2
3
apw@pinky$ git cat-file blob :2:this
1
2b
3
apw@pinky$ git cat-file blob :3:this
1
2a
3
apw@pinky$ cat this
1
<<<<<<< HEAD/this
2b
=======
2a
>>>>>>> c2acfdd8e6a50e571a007744e023c65c7b188dbf/this
3
-apw
prev parent reply other threads:[~2006-10-19 16:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-19 13:45 "stage files" vs "cached files" Jerome Lovy
2006-10-19 15:58 ` Linus Torvalds
2006-10-19 15:58 ` Andy Whitcroft [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4537A0BC.5040301@shadowen.org \
--to=apw@shadowen.org \
--cc=git@vger.kernel.org \
--cc=t2a2e9z8ncbs9qg@brefemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
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 NNTP newsgroup(s).