On Sat, Jun 18, 2022 at 12:45:30PM +0200, Fabrice Creuzot wrote: > When we are reading a "git diff", all paths are prefixed with "a/" and "b/". > Example: > > diff --git a/xyz > index 4aa4b5230..1c2b8b69e 100644 > --- a/xyz > +++ b/xyz > @@ -1,7 +1,7 @@ > > > With my terminal, I double click on the path to select the full path for > copy. > > Then, when I paste: "git log a/xyz", > git says: unknown revision or path not in the working tree > > Ok, I need to remove the "a/" or "b/". > But, is git can understand that "a/xyz" is "xyz" because "a/xyz" does not > exist? A quick answer: pass `git diff` the "--no-prefix" command-line option to suppress generation of these prefixes. A bit of historical context. Please note that `git diff` - at least by default - generates its output using the format known as "unified diff" which was invented an implemented way before Git was concieved [1]. Quite probably on your system you have access to the two command line tools - `diff` and `patch`, - one of which generates diffs by comparing two files, and another one being able to update a file using a patch information produced by the former. The diff format records the pathnames of the files compared when the patch data was generated. Now consider that a patch file can describe changes to apply to any set of files. In order to achieve this, the format has to name the files to be used. Now consider that the diff format can use used for two conceptually slightly different purposes: - A patch file in this format can describe a set of "concrete" changes. Say, you pass a patch file to someone, they just run `patch` on it and that tool patches a set of files no matter where it was run from. - A patch file in this format can describe a set of changes intended to be applied to a particular state of a file or a set of files, possibly comprising a hierarchy, located anywhere in the target filesystem. A good example is a source tree of a software project: a user can fetch a tarball with a software project and unpack it everywhere they wish. They then should be able to apply a patch file to that unpacked tree. Note that in the former case the names of the names of the files listed in a patch file may not share even the smallest common prefix while in the second case they will have the same prefix, and the prefix may not even be needed at all. Historically the patch files to be used in the second case were generated by running a tool like `diff` against the two hierarchies of files: a source, unmodified directory, and the copy of that directly with the necessary modifications. That is, you'd run something like $ diff -u srcdir modified > changes.patch and because of that the generated patch file would naturally contain file names starting with "srcdir/" and "modified/" prefixes. The tool to apply patch files, `patch`, has a command-line option "-p" (for "prefix") which can be used to strip the specified number of prefix directories from the names of the files when applying a patch file. So to apply a patch generated by comparing two directory hierarchy you'd routinely pass "-p1" to that tool, like in $ cd srcdir $ patch -p1 < changes.patch OK, so you can now note that `git diff` is different from the classical patch maniputation tools in that its operation is somewhat virtualized: by default it generates a patch describing the set of differences between the work tree and the index, and can be told to generate a patch between sets of files in named revisions and so on. So there's no two directories physically existing on the file system and so `git diff` generates fake prefixes. Exactly why it does so by default, I don't know, but I suppose it's just to be in line with the classical use case explained above which was in widespread use before Git even existed. 1. https://en.wikipedia.org/wiki/Diff#Unified_format
