git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git a/xyz or b/xyz

From
FCFabrice Creuzot <code@luigifab.fr>
Date
Jun 24, 2022, 15:58 UTC
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 :
Show 95 quoted lines
> 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
> 
Previous: Konstantin Khomoutov
Message 5 of 5 in “git a/xyz or b/xyz”
  1. Fabrice CreuzotJun 18, 2022
  2. Shaoxuan YuanJun 18, 2022
  3. Shaoxuan YuanJun 18, 2022
  4. Konstantin KhomoutovJun 20, 2022
  5. Fabrice CreuzotJun 24, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.