Re: Call Me Gitless

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

Marcus Griep <neoeinstein@gmail.com> writes:

> Junio C Hamano wrote:
>
>> This implements Daniel's idea to indicate what are compared by using
>> prefix different from the traditional a/ and b/ in the textual diff
>> header:
>> 
>>     "git diff" compares the (i)ndex and the (w)ork tree;
>>     "git diff HEAD" compares a (c)ommit and the (w)ork tree;
>>     "git diff --cached" compares a (c)ommit and the (i)ndex;
>>     "git diff HEAD:f /tmp/f" compares an (o)bject and (w)ork tree.
>> 
>> Because these mnemonics now have meanings, they are swapped when reverse
>> diff is in effect.
>
> I like this proposal-ish; making the prefixes more intuitive could be
> useful when looking at a bare diff from git too.  I'd put some time in
> to help implement this.

What I did not bother in the patch is --no-index codepath, but with the
recent refactoring of it to separate it out from the normal "index vs work
tree" codepath, I would expect it to be trivial to use "1/" vs "2/" (or
"old/" and "new/") prefixes for them.  I didn't actually look, though.

I also left "-c" and "--cc" unmodified.  Daniel's "have many patches to
apply, but cannot readily tell in which direction they were generated"
use-case won't involve them, and reverse diff won't make sense with --cc,
so that should be Ok.

And obviously I didn't adjust the test vectors and documentation, which is
needed if somebody is serious enough about actually making this part of
the official system.

But be warned that this has two downsides, one minor, and one rather
major:

 * Using non-standard prefix affects git-patch-id output.  This would not
   affect "git-format-patch --ignore-if-in-upstream", "git-cherry",
   "git-rebase" because they all use internal patch-id generation, but
   third party scripts that feed patches to "git-patch-id" and compare its
   output with precomputed patch-id database to cull duplicates will be
   affected.

 * Similarly, scripts that assume more about "git diff" output than that
   they are meant to be applied with depth 1 may break.

   I think gitweb would be Ok, because I do not think it would try parsing
   a textual diff, stripping out a/ (or b/), to figure out the paths being
   affected.  Even if it did, it would be doing two-tree form (iow, it
   does not use working tree at all) which I deliberately kept to use a/
   vs b/ with my patch, so it should be fine.  I do not offhand recall how
   cvsserver generates its diff output, but it would also be fine as the
   server side would do two-tree form and nothing else.

   But nobody knows what third-party scripts are assuming.  They may be
   parsing the pathnames, stripping a/ and b/ away.