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?

jub0bs
  • 60,866
  • 25
  • 183
  • 186
qazwsx
  • 25,536
  • 30
  • 72
  • 106

1 Answers1

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
jub0bs
  • 60,866
  • 25
  • 183
  • 186
  • What's the relation between the `` and the ``? – qazwsx Jan 26 '15 at 21:59
  • @qazwsx 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). – hobbs Jan 26 '15 at 22:16
  • Is the content addressed by `` (i.e. an SHA-1 digest) typically *part of* the file content of ``? – qazwsx Jan 26 '15 at 22:18
  • @qazwsx I don't understand your question in your last comment. Can you clarify? – jub0bs Jan 26 '15 at 22:22
  • If `` and `` 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 `` value a part of the file ``? – qazwsx Jan 26 '15 at 22:26
  • @qazwsx `` and `` are completely independent, but you still need to know which content (identified by ``) is associated with which file (identified by its path ``); each line in the output of `git ls-files -s` shows you this correspondence. – jub0bs Jan 26 '15 at 22:29
  • By `associated` do you mean that the content identified by `` exists in the file identified by ``? "associated" is an abstract verb. In what exact sense are they associated? – qazwsx Jan 26 '15 at 22:33
  • *[...] do you mean that the content identified by `` exists in the file identified by ``?* 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. – jub0bs Jan 26 '15 at 22:36
  • OK, the explicit experiment you added demonstrated that the data digested by the identical SHA-1 hash values *exist* in both the files. – qazwsx Jan 26 '15 at 22:51
  • @qazwsx 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. – jub0bs Jan 26 '15 at 22:57
  • @jubobss In my case, I have same file displayed 2ice as a result of this command as per post here https://stackoverflow.com/questions/54001982/git-add-wont-stage-files-git-cache-confused?noredirect=1#comment94849724_54001982 Any chance you can take a look and comment? Much appreciated – pixel Jan 05 '19 at 05:58
  • @pixel Yours is a different question. Answering it here, in the comment section of this answer, isn't appropriate. – jub0bs Jan 05 '19 at 09:47
  • @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 anyways – pixel Jan 06 '19 at 01:29
  • @pixel You can always ask a separate question. – jub0bs Jan 06 '19 at 08:48
  • @jubobs yup, in the lprovided link – pixel Jan 06 '19 at 17:40