Marcus Griep <neoeinstein@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
