I am still trying to understand how git works when I ran into this question.

I have a local repo named training. And the full path where it is is /c/training

After a few commits, when I tried to get the file names and their md5sum value of the files that were part of the commit using the Hash Commit ( SHA value ), using the following command

git diff-tree --no-commit-id --name-only -r  08dca334d9b6aa416b377566a8d8606f71b5b8da | xargs -I {} md5sum {}

The Output I got was

10b2804a72f5de19bd04b1f500ab840f *folder/file.txt
c3244a3bf0221587a47fc44ebd2c5aa3 *folder/secondnewfile.txt

I was expecting the command to show the full path like /c/training/folder/file.txt

Is it because training was initialised ( as the local repo) and git only tracks from there and is not able to or cannot know the full path to the file ? Or is something wrong with the way I have written the command?

CodePudding user response：

Git almost never uses absolute paths. The reason is simple: absolute paths are usually bad.

There are occasions where absolute paths are good, but to turn relative path R into absolute path A rooted at $start, we simply stick $start (plus a trailing slash if needed—here I'll just assume it's in $start) in front of R. If we have all output as absolute paths and want relative ones, we can strip $start from each line, but any line that doesn't start with $start is now literally impossible to deal with: it's not relative to the $start we chose.

This means the interconversion direction is trivial for R ⇒ A but hard for A ⇒ R. As such, if it's possible to define a system in terms of relative paths R, we should do so. It is in Git, and Git does so.

This also allows us to pick up a Git repository and move it elsewhere. If Git repositories stored absolute paths, we would not be able to do that. Relative paths good, absolute paths bad: it's a useful mantra.¹

¹Although vaguely disturbingly close to "four legs good, two legs bad".