What is the meaning of the different fields in the output of `git ls-files -s`?
Asked Answered
C

1

4

In Git, a typical line of the result returned by command git ls-files -s looks like

100755 be2c2e9b0966253096472d4b482c458bc892e493 0 .gitignore

What do those fields mean?

Candidacandidacy answered 26/1, 2015 at 21:46 Comment(0)
F
5

Look no further than the git ls-files man page:

git ls-files just outputs the filenames unless --stage is specified in which case it outputs:

       [<tag> ]<mode> <object> <stage> <file>

(The --stage flag is equivalent to -s.)

What do those fields mean?

  • <mode> are the mode bits. More details in How to read the mode field of git-ls-tree's output
  • <object> is the SHA of the corresponding blob, i.e. a unique identifier for the contents of the file in question.
  • <stage> is the stage number, which is normally 0, but takes nonzero values for files with merge conflicts.
  • <file> is simply the path to the file.

You also ask, in one of your follow-up comment,

What's the relation between the <object> and the <file>?

They're completely independent, since only the contents of a file (not its path/filename) are used to generated the hash associated with it. To convince yourself of that, you can conduct the following experiment in a toy repository:

# Set things up
$ mkdir testgit
$ cd testgit/
$ git init

# Write the same contents to two files
$ printf "foo\n" > README.md
$ printf "foo\n" > bar.txt

# Stage the two files and run git ls-files
$ git add .
$ git ls-files -s

100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 0    README.md
100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 0    bar.txt

Note that, even though the two files have different names, they have identical SHAs, since they have the same contents.

Friesen answered 26/1, 2015 at 21:50 Comment(15)
What's the relation between the <object> and the <file>?Candidacandidacy
@Candidacandidacy the object is the hash of the file contents, which is also the address of the git object used to store the file contents (since git is, in essence, a content-addressable filesystem that happens to have a version control system built on top of it).Monreal
Is the content addressed by <object> (i.e. an SHA-1 digest) typically part of the file content of <file>?Candidacandidacy
@Candidacandidacy I don't understand your question in your last comment. Can you clarify?Friesen
If <object> and <file> are really independent and has no relation whatsoever, then it won't be useful to show them in the same lines. Isn't that the data content digested by the <object> value a part of the file <file>?Candidacandidacy
@Candidacandidacy <object> and <file> are completely independent, but you still need to know which content (identified by <object>) is associated with which file (identified by its path <file>); each line in the output of git ls-files -s shows you this correspondence.Friesen
By associated do you mean that the content identified by <object> exists in the file identified by <file>? "associated" is an abstract verb. In what exact sense are they associated?Candidacandidacy
[...] do you mean that the content identified by <object> exists in the file identified by <file>? Yes. Git has to keep track of that information; otherwise, it wouldn't know which contents is associated with which of the files it's tracking.Friesen
OK, the explicit experiment you added demonstrated that the data digested by the identical SHA-1 hash values exist in both the files.Candidacandidacy
@Candidacandidacy I'm not sure what you mean by that. In this case, Git actually figures out that the contents is the same (since the hash is the same) and stores only one copy, but, as part of its bookkeeping, associates it to the two different files.Friesen
@jubobss In my case, I have same file displayed 2ice as a result of this command as per post here #54002482 Any chance you can take a look and comment? Much appreciatedJohore
@Johore Yours is a different question. Answering it here, in the comment section of this answer, isn't appropriate.Friesen
@jubobs I know, I thought maybe you can see something strange and provide some hints for my question, too. I noticed by your answer, you are knowledgable about the topic, that is all :). Thanks anywaysJohore
@Johore You can always ask a separate question.Friesen
@jubobs yup, in the lprovided link🙂Johore

© 2022 - 2024 — McMap. All rights reserved.