Thanks! --no-prefix do the job.
Le 20/06/2022 à 13:12, Konstantin Khomoutov a écrit :
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
