Re: [BUG] git diff --(src|dst)-prefix=// causes spurious "(new|deleted) file mode"

From: Junio C Hamano <gitster@pobox.com>
Date: May 28, 2014, 17:29 UTC
Message-ID: <xmqq38fterrh.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAM-tV-9vQPPj+TemYnzjRMTjaHqwo3qq=WWJ89VnRMAeYXHZZw@mail.gmail.com>

Noam Postavsky <npostavs@users.sourceforge.net> writes:

Show 15 quoted lines

> % git init
> Initialized empty Git repository in /home/npostavs/tmp/scratch/.git/
> % echo foo > x
> % git add x
> % git commit -m x
> [master (root-commit) 41be1f2] x
>  1 file changed, 1 insertion(+)
>  create mode 100644 x
> % echo bar > x
> % git diff  | head -3
> diff --git i/x w/x
> index 257cc56..5716ca5 100644
> --- i/x
> % git diff --dst-prefix=// | head -3
> diff --git i/x //x

The feature these options implement was never designed to accept anything other than "foo/bar/" (i.e. a relative path-looking thing that ends with "/" and no funnies such as duplicated slashes, in order to replace the standard "a/" and "b/"). I think the command line parsing code of src/dst-prefix trusts the user too much not to feed nonsense like the above. They may want to be tightened.

> Background: trying to find a prefix that can't show up in file names
> in order to make parsing easier.
> https://github.com/magit/magit/pull/1379
> https://github.com/magit/magit/pull/1383

It may be worth studying how "git apply" finds what the paths are and use the same rule for consistency. IIRC, the rules are roughly:

 - In a renaming/copying patch, you will have "rename/copy from/to"
   header separately.  There is no need to parse the "diff --git"
   line at all;

 - Otherwise, you will have "a/SOMETHING b/SOMETHING" (SOMETHING are
   repeated because there is no rename involved).