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?
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?
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.
<object>
(i.e. an SHA-1 digest) typically part of the file content of <file>
? –
Candidacandidacy <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 <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 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 <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 © 2022 - 2024 — McMap. All rights reserved.
<object>
and the<file>
? – Candidacandidacy