Hi.
is there any reason why git insists diffs be -p1 format ?
it makes it hard to import a diff generated by svn (-p0).
thanks!
Greg KHRe: Importing diffs
On Mon, Jan 30, 2006 at 02:07:51PM +0000, Ian Molton wrote:
> Hi. > > is there any reason why git insists diffs be -p1 format ?
Because that's the default for what the Linux kernel project uses? :)
> it makes it hard to import a diff generated by svn (-p0).
I'm pretty sure that svn can output -p1 patches, I've done it in the past...
thanks,
greg k-h
Daniel Barkalow[PATCH] Make apply accept the -pNUM option like patch does.
This only applies to traditional diffs, not to git diffs.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
--- On Mon, 30 Jan 2006, Ian Molton wrote:
> Hi. > > is there any reason why git insists diffs be -p1 format ?
Try this patch. Completely untested; if it works, tell Junio. :)
Documentation/git-apply.txt | 6 +++++- apply.c | 8 ++++++-- 2 files changed, 11 insertions(+), 3 deletions(-)
2490f3129103a0eae9013eb2a6f564f4a7290fbd
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index 51c7d47..75076b6 100644 --- a/Documentation/git-apply.txt +++ b/Documentation/git-apply.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git-apply' [--stat] [--numstat] [--summary] [--check] [--index] [--apply] - [--no-add] [--index-info] [--allow-binary-replacement] [-z] + [--no-add] [--index-info] [--allow-binary-replacement] [-z] [-pNUM] [<patch>...] DESCRIPTION @@ -68,6 +68,10 @@ OPTIONS backslash characters replaced with `\t`, `\n`, and `\\`, respectively. +-p<n>:: + Remove <n> leading slashes from traditional diff paths. The + default is 1. + --apply:: If you use any of the options marked ``Turns off "apply"'' above, git-apply reads and outputs the diff --git a/apply.c b/apply.c index c471a82..79e23a7 100644 --- a/apply.c +++ b/apply.c @@ -19,6 +19,7 @@ static const char *prefix; static int prefix_length = -1; +static int p_value = 1; static int allow_binary_replacement = 0; static int check_index = 0; static int write_index = 0; @@ -31,7 +32,7 @@ static int no_add = 0; static int show_index_info = 0; static int line_termination = '\n'; static const char apply_usage[] = -"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [-z] <patch>..."; +"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [-z] [-pNUM] <patch>..."; /* * For "diff-stat" like behaviour, we keep track of the biggest change @@ -217,7 +218,6 @@ static char * find_name(const char *line */ static void parse_traditional_patch(const char *first, const char *second, struct patch *patch) { - int p_value = 1; char *name; first += 4; // skip "--- " @@ -1799,6 +1799,10 @@ int main(int argc, char **argv) excludes = x; continue; } + if (!strncmp(arg, "-p", 2)) { + p_value = atoi(arg + 2); + continue; + } if (!strcmp(arg, "--no-add")) { no_add = 1; continue;
-- 0.99.6.g3480
Linus TorvaldsRe: [PATCH] Make apply accept the -pNUM option like patch does.
On Tue, 31 Jan 2006, Daniel Barkalow wrote:
> > This only applies to traditional diffs, not to git diffs.
Also, be careful: the default for git-apply is very different from the default for a regular "patch".
"patch" without any "-p" at all will try to automagically figure out the right file, which has burnt me more than once when you have the same name (usually "Makefile") in multiple sub-directories and "patch" makes the wrong automagic guess.
git-apply with this patch will continue to use -p1. No guessing, no gray areas.
I do believe that the right thing to do is to just make SVN output "-p1" patches (I cannot imagine that you can't do so, since -p1 is a much saner format than -p0), but I guess teaching git-apply to take -pN for traditional patches is fine.
But if somebody suggests we do the automatic thing that "patch" does, I'll scream. Too many times have I been burnt by patch being "helpful" (in general, patch by default will try very hard to apply a patch, whether it makes sense or not).
Linus