git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* "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).