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

[Junio C Hamano <gitster@pobox.com>]

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

> % 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).