All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: git@vger.kernel.org
Subject: Re: Filenames and prefixes in extended diffs
Date: Wed, 13 Jan 2010 16:16:21 -0800	[thread overview]
Message-ID: <7vfx69k0bu.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <201001131713.05505.agruen@suse.de> (Andreas Gruenbacher's message of "Wed\, 13 Jan 2010 17\:13\:05 +0100")

Andreas Gruenbacher <agruen@suse.de> writes:

> Can git be changed to ...

Just to save your time coming up with more ways to *change* git diff...

Even though I wouldn't say _any_ change is too late to bring in, change in
the output format from "git diff" family _must_ be usable by "git apply"
people have been using for the last 4 years or so.

Suppose your updated version of "git diff" with a certain set of options
produces output A, which is different from the output B you would get out
of today's "git diff" that is run with the same set of options.

If "git apply" people have been using understands B (i.e. current output)
and does something, the format change between A and B must be designed in
such a way that the same "git apply" accepts A (i.e. your output) and do
the same thing.

Two examples:

 - "git diff -M" (or "git show -M") is _defined_ to show the filenames
   without prefix on "rename from" line, and deployed "git apply" relies
   on this definition to apply the patch to the file the patch was meant
   to apply.  If your modified "git diff -M" changes it to add the prefix,
   and existing "git apply" changes behaviour (either by rejecting your
   output, or applying the patch to a wrong file), then such a change has
   *no chance* of getting in.  It is merely a breakage.

 - If you say "git diff --src-prefix=a/b/c --dst-prefix=x/y", it _might_
   produce something "git apply" won't grok (I haven't checked this,
   though).  You can suggest to change the output from such a case to work
   better.  We didn't work as expected so a change _could_ be a fix.

The output from "git diff --no-index" is an exception to the above rule.
It is primarily for people who have unmanaged contents and want to use
features of the git diff engine that are not found in other people's diff
implementations (e.g. wordwise colored diff), and the header part of its
output does not currently follow "git diff" convention to be grokkable by
"git apply".

Fixing _that_ is a welcome change, but I suspect that there are corner
cases, e.g. "git diff --no-index frotz-1.2.36/ /tmp/frotz/" (i.e. you have
a pristine version in frotz-1.2.36 directory, but your modified version is
in /tmp/frtoz/) that might make fixing it fundamentally impossible (I
haven't looked into it for a long time, so it could be easy, but my gut
feeling is it isn't).

  parent reply	other threads:[~2010-01-14  0:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-13 16:13 Filenames and prefixes in extended diffs Andreas Gruenbacher
2010-01-13 19:49 ` Junio C Hamano
2010-01-14  0:16 ` Junio C Hamano [this message]
2010-01-15 13:32   ` Nanako Shiraishi
2010-01-15 18:09     ` Junio C Hamano
2010-01-15 20:50       ` [PATCH] grep: prepare to run outside of a work tree Junio C Hamano
2010-01-15 20:52       ` [PATCH] grep --no-index: allow use of "git grep" outside a git repository Junio C Hamano
2010-01-15 21:08         ` Jeff King
2010-01-16  1:05           ` Junio C Hamano
2010-01-16  1:15             ` Jeff King
2010-01-16  4:15               ` Junio C Hamano
2010-01-16  6:51                 ` David Aguilar
2010-01-16  7:21                   ` Junio C Hamano
2010-01-18  1:51                 ` Jeff King
2010-01-18  3:35                   ` Junio C Hamano
2010-01-18  4:02                     ` Junio C Hamano
2010-01-18  5:57                       ` Jeff King
2010-01-18  6:30                         ` Junio C Hamano
2010-01-18  6:50                           ` Jeff King
2010-01-18 23:22   ` Filenames and prefixes in extended diffs Andreas Gruenbacher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vfx69k0bu.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=agruen@suse.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.