Laurent Arnoud <laurent@xxxxxxxxxx> writes: > I don't know if its a bug but I founded strange that I needed to use an alias > "git -c diff.noprefix=false format-patch" to generate a patch that I can apply > directly with "git am". The same thing can be said about the diff.relative option. As I do not use either of these variables myself, I am somewhat indifferent, if those who set these variables find the consequences of doing so unpleasant. As people often say, if it hurts, then... ;-) Because the recipient of format-patch output who consumes it is typically different from the one who generates it, it probably does not make much sense to attempt linking diff.noprefix=true with the -p0 option (there isn't even a configuration for 'git am -p<num>', if I am not mistaken). Depending on the project a user works with, allowing log/show/format-patch to honor certain diff.* configuration variables, without a way to countermand them with more specific configuration for log/show/format-patch, may smell like a bug. I am not sure where to draw the line, though. Would we treat only format-patch and no other commands in the log family specially? Would we treat each commands in the log family specially and separately, so that you could say "diff and show uses noprefix, but 'log -p' and 'whatchanged' uses the standard a/ and b/ prefix and format-patch uses old/ and new/ prefix" independently? > I didn't know the -p option but to send a patch to a > mailinglist it should have the prefix I guess ? The participants in this project would certainly find it unusual when they see a prefix-less patch. There probably are projects older than Git whose convention is to use .noprefix; we didn't want to force them to switch and instead accomodated their preference with .noprefix but in hindsight, it may have been a better idea to force one true way to everybody, which would have kept the world simpler. I dunno.
