* "stage files" vs "cached files"
@ 2006-10-19 13:45 Jerome Lovy
2006-10-19 15:58 ` Linus Torvalds
2006-10-19 15:58 ` Andy Whitcroft
0 siblings, 2 replies; 3+ messages in thread
From: Jerome Lovy @ 2006-10-19 13:45 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: "stage files" vs "cached files"
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
1 sibling, 0 replies; 3+ messages in thread
From: Linus Torvalds @ 2006-10-19 15:58 UTC (permalink / raw)
To: Jerome Lovy; +Cc: Git Mailing List
On Thu, 19 Oct 2006, Jerome Lovy wrote:
>
> 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"
That is indeed confusing.
It shouldn't be "stage files". It should be "file stages".
The "stage" of a file is something that is meaningful on merges. Normally
all files are in "stage 0", which means that it's fully merged. So when
you do
git ls-files --stage
you'll see a listing of all the files, with their file modes, SHA1's,
"stage" and filename. And you'll basically always see "0" in the stage
column.
But if you have had a merge that didn't resolve automatically, you can see
the same filename listed up to three times, with stages 1, 2 and 3 (a zero
will never be combined with any other stage - you'll only see a zero
alone).
That just shows how that particular file came to be: a "stage 1" entry is
the base branch version (the "common ancestor"), while stages 2 and 3 are
the first and second branch respectively.
> I'm a bit confused. Is maybe a "stage file" entry missing in the glossary?
That term doesn't exist, so it shouldn't be in the glossary (or in any
man-pages). But the "merge stage" _of_ a file is a real concept.
Linus
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: "stage files" vs "cached files"
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
1 sibling, 0 replies; 3+ messages in thread
From: Andy Whitcroft @ 2006-10-19 15:58 UTC (permalink / raw)
To: t2a2e9z8ncbs9qg; +Cc: git
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-10-19 16:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).