From: Fabrice Creuzot <code@luigifab.fr>
Date: Fri, 24 Jun 2022 15:58:56 GMT
Subject: Re: git a/xyz or b/xyz
Message-ID: <7c490fea-fa8a-0245-5b3f-981b8797a7cd@luigifab.fr>
In-Reply-To: <20220620111230.ck7nkouzkviidtcu@carbon>

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
>