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
Linus TorvaldsRe: "stage files" vs "cached files"
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
Andy WhitcroftRe: "stage files" vs "cached files"
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