git a/xyz or b/xyz

git a/xyz or b/xyz

[Fabrice Creuzot]

Hello

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?

Thanks

Re: git a/xyz or b/xyz

[Shaoxuan Yuan]

On Sat, Jun 18, 2022 at 6:50 PM Fabrice Creuzot <code@luigifab.fr> wrote:
>
> Hello
>
> 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?
>
> Thanks

Hi Fabrice,

You can think that "a/" stands for "before" or "old content", whereas
 "b/" stands for "after" or "new content". Paths are prefixed with these
to indicate which is before and which is after.

For example, when you call "git diff", it is to "view the changes you made
relative to the index (staging area for the next commit)".
In this case, "before" is the index, namely "a/", whereas "after"
is your current working tree, namely "b/".

-- 
Thanks & Regards,
Shaoxuan

Re: git a/xyz or b/xyz

[Shaoxuan Yuan]

On Sat, Jun 18, 2022 at 7:09 PM Shaoxuan Yuan <shaoxuan.yuan02@gmail.com> wrote:
>
> On Sat, Jun 18, 2022 at 6:50 PM Fabrice Creuzot <code@luigifab.fr> wrote:
> >
> > Hello
> >
> > 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?
> >
> > Thanks
>
> Hi Fabrice,
>
> You can think that "a/" stands for "before" or "old content", whereas
>  "b/" stands for "after" or "new content". Paths are prefixed with these
> to indicate which is before and which is after.
>
> For example, when you call "git diff", it is to "view the changes you made
> relative to the index (staging area for the next commit)".
> In this case, "before" is the index, namely "a/", whereas "after"
> is your current working tree, namely "b/".

A more precise way of saying is "a/" stands for source, whereas "b/"
stands for destination.

-- 
Thanks & Regards,
Shaoxuan

Re: git a/xyz or b/xyz

[Konstantin Khomoutov]

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

Re: git a/xyz or b/xyz

[Fabrice Creuzot]

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
>