On Tue, 15 Jan 2008, Linus Torvalds wrote:

quoted text
> On Tue, 15 Jan 2008, Junio C Hamano wrote:
> >
> > If a non-standard prefix is used by --no-prefix, --src-prefix,
> > or --dst-prefix options, the resulting diff becomes something
> > git-apply would not grok.  In such a case, we should not trigger
> > the more strict check git-apply does for patches in "diff --git"
> > format.
> 
> I think this is wrong.
> 
> If we do any git-specific stuff, we need to have that "--git" thing there. 
> That is *not* just limited to the prefix, but to all the other things git 
> diffs can do: renames, mode changes, etc.

Well, part of the issue is that, if you drop the prefix, then *git* can't 
understand the resulting patch (because --git causes git-apply to use 
open-coded -p1 handling of names, which won't be right).

I suppose the other option is to have the header in this case be:

diff --git --src-prefix= --dst-prefix= filename filename

so that apply can figure out what diff did correctly.

quoted text
> > Metainformation (e.g. "index", "similarity", etc.) lines will
> > safely be ignored by patch and git-apply (even when the latter
> > parses a non-git diff output), so this patch does not bother
> > stripping them away.
> 
> It's not necessarily safe to ignore some of them, like the rename info. If 
> you see a rename patch and don't understand it as a rename, it's 
> pointless.
> 
> So I would argue that you need something stronger to say "don't do a git 
> diff", and that should also disallow rename detection at a minimum. Quite 
> frankly, any program that is so stupid as to not accept current git 
> patches (ie TortoiseSVN), then we damn well shouldn't just disable the 
> most trivial part of it. We should make sure that we do not enable *any* 
> of the rather important extensions: even if ToirtoiseSVN would ignore 
> them, if ignoring them means that it mis-understands the diff, it 
> shouldn't be allowed at all.
> 
> So maybe a --standard-diff option that removes the "--git" part, but also 
> removes everything else.

That seems wise to me. We should be able to generate patches that are 
accessible to programs that can't follow any clever instructions. I think 
the point of the "Index:" header is that these programs will freak out if 
two filenames don't match (or, more likely, break in some way), and it 
means you can't sensibly generate patches that upset them for deletes or 
creates.

	-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html