mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-01 14:57:52 +01:00
Code Activity
git/apply.c

1313 lines
29 KiB
C
Raw Normal View History

Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
/*
* apply.c
*
* Copyright (C) Linus Torvalds, 2005
*
* This applies patches on top of some (arbitrary) version of the SCM.
*
* NOTE! It does all its work in the index file, and only cares about
* the files in the working directory if you tell it to "merge" the
* patch apply.
*
* Even when merging it always takes the source from the index, and
* uses the working tree as a "branch" for a 3-way merge.
*/
#include <ctype.h>
#include "cache.h"
// We default to the merge behaviour, since that's what most people would
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
// expect.
//
// --check turns on checking that the working tree matches the
// files that are being modified, but doesn't apply the patch
// --stat does just a diffstat, and doesn't actually apply
// --show-files shows the directory changes
//
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
static int merge_patch = 1;
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
static int check_index = 0;
git-apply: actually apply patches and update the index We update the index only if the "--index" flag is given, so you can actually use this as a strange kind of "patch" program even for non-git usage. Not that you'd likely want to, but it comes in handy for testing. This _should_ more or less get everythign right, but as usual I leave the testing to the usrs..
2005-06-05 23:05:43 +02:00
static int write_index = 0;
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
static int diffstat = 0;
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
static int check = 0;
static int apply = 1;
static int show_files = 0;
static const char apply_usage[] = "git-apply [--stat] [--check] [--show-files] <patch>";
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
/*
* For "diff-stat" like behaviour, we keep track of the biggest change
* we've seen, and the longest filename. That allows us to do simple
* scaling.
*/
static int max_change, max_len;
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
/*
* Various "current state", notably line numbers and what
* file (and how) we're patching right now.. The "is_xxxx"
* things are flags, where -1 means "don't know yet".
*/
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
static int linenr = 1;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
struct fragment {
unsigned long oldpos, oldlines;
unsigned long newpos, newlines;
const char *patch;
int size;
struct fragment *next;
};
struct patch {
git-apply: pick up default filenames from "diff --git" header line Pure mode changes, and deletes or creates of empty files won't have this information anywhere else.
2005-05-26 22:11:24 +02:00
char *new_name, *old_name, *def_name;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
unsigned int old_mode, new_mode;
int is_rename, is_copy, is_new, is_delete;
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
int lines_added, lines_deleted;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
struct fragment *fragments;
git-apply: actually apply patches and update the index We update the index only if the "--index" flag is given, so you can actually use this as a strange kind of "patch" program even for non-git usage. Not that you'd likely want to, but it comes in handy for testing. This _should_ more or less get everythign right, but as usual I leave the testing to the usrs..
2005-06-05 23:05:43 +02:00
char *result;
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
unsigned long resultsize;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
struct patch *next;
};
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
#define CHUNKSIZE (8192)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
#define SLOP (16)
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
static void *read_patch_file(int fd, unsigned long *sizep)
{
unsigned long size = 0, alloc = CHUNKSIZE;
void *buffer = xmalloc(alloc);
for (;;) {
int nr = alloc - size;
if (nr < 1024) {
alloc += CHUNKSIZE;
buffer = xrealloc(buffer, alloc);
nr = alloc - size;
}
nr = read(fd, buffer + size, nr);
if (!nr)
break;
if (nr < 0) {
if (errno == EAGAIN)
continue;
die("git-apply: read returned %s", strerror(errno));
}
size += nr;
}
*sizep = size;
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
/*
* Make sure that we have some slop in the buffer
* so that we can do speculative "memcmp" etc, and
* see to it that it is NUL-filled.
*/
if (alloc < size + SLOP)
buffer = xrealloc(buffer, size + SLOP);
memset(buffer + size, 0, SLOP);
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
return buffer;
}
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
static unsigned long linelen(const char *buffer, unsigned long size)
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
{
unsigned long len = 0;
while (size--) {
len++;
if (*buffer++ == '\n')
break;
}
return len;
}
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
static int is_dev_null(const char *str)
{
return !memcmp("/dev/null", str, 9) && isspace(str[9]);
}
git-apply: don't try to be clever about filenames and the index It just causes things like "git-apply --stat" to parse traditional patch headers differently depending on what your index is, which is nasty.
2005-06-01 00:05:59 +02:00
#define TERM_SPACE 1
#define TERM_TAB 2
git-apply: start using the index file information. Right now we only use it to figure out what the filename might be when that is ambiguous, but we'll get there..
2005-05-24 04:13:55 +02:00
static int name_terminate(const char *name, int namelen, int c, int terminate)
{
if (c == ' ' && !(terminate & TERM_SPACE))
return 0;
if (c == '\t' && !(terminate & TERM_TAB))
return 0;
return 1;
}
static char * find_name(const char *line, char *def, int p_value, int terminate)
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
{
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
int len;
const char *start = line;
char *name;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
for (;;) {
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
char c = *line;
git-apply: start using the index file information. Right now we only use it to figure out what the filename might be when that is ambiguous, but we'll get there..
2005-05-24 04:13:55 +02:00
if (isspace(c)) {
if (c == '\n')
break;
if (name_terminate(start, line-start, c, terminate))
break;
}
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
line++;
if (c == '/' && !--p_value)
start = line;
}
if (!start)
return def;
len = line - start;
if (!len)
return def;
/*
* Generally we prefer the shorter name, especially
* if the other one is just a variation of that with
* something else tacked on to the end (ie "file.orig"
* or "file~").
*/
if (def) {
int deflen = strlen(def);
if (deflen < len && !strncmp(start, def, deflen))
return def;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
}
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
name = xmalloc(len + 1);
memcpy(name, start, len);
name[len] = 0;
free(def);
return name;
}
/*
* Get the name etc info from the --/+++ lines of a traditional patch header
*
* NOTE! This hardcodes "-p1" behaviour in filename detection.
git-apply: start using the index file information. Right now we only use it to figure out what the filename might be when that is ambiguous, but we'll get there..
2005-05-24 04:13:55 +02:00
*
* FIXME! The end-of-filename heuristics are kind of screwy. For existing
* files, we can happily check the index for a match, but for creating a
* new file we should try to match whatever "patch" does. I have no idea.
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
*/
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static void parse_traditional_patch(const char *first, const char *second, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
int p_value = 1;
char *name;
first += 4; // skip "--- "
second += 4; // skip "+++ "
if (is_dev_null(first)) {
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->is_new = 1;
patch->is_delete = 0;
git-apply: pick up default filenames from "diff --git" header line Pure mode changes, and deletes or creates of empty files won't have this information anywhere else.
2005-05-26 22:11:24 +02:00
name = find_name(second, NULL, p_value, TERM_SPACE | TERM_TAB);
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->new_name = name;
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
} else if (is_dev_null(second)) {
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->is_new = 0;
patch->is_delete = 1;
git-apply: don't try to be clever about filenames and the index It just causes things like "git-apply --stat" to parse traditional patch headers differently depending on what your index is, which is nasty.
2005-06-01 00:05:59 +02:00
name = find_name(first, NULL, p_value, TERM_SPACE | TERM_TAB);
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->old_name = name;
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
} else {
git-apply: don't try to be clever about filenames and the index It just causes things like "git-apply --stat" to parse traditional patch headers differently depending on what your index is, which is nasty.
2005-06-01 00:05:59 +02:00
name = find_name(first, NULL, p_value, TERM_SPACE | TERM_TAB);
name = find_name(second, name, p_value, TERM_SPACE | TERM_TAB);
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->old_name = patch->new_name = name;
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
}
if (!name)
die("unable to find filename in patch at line %d", linenr);
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_hdrend(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
return -1;
}
git-apply: more consistency checks on gitdiff filenames There's some duplication of filenames when doing filename operations (creates, deletes, renames and copies), and this makes us verify that the pathnames match when they should.
2005-05-24 04:54:55 +02:00
/*
* We're anal about diff header consistency, to make
* sure that we don't end up having strange ambiguous
* patches floating around.
*
* As a result, gitdiff_{old|new}name() will check
* their names against any previous information, just
* to make sure..
*/
static char *gitdiff_verify_name(const char *line, int isnull, char *orig_name, const char *oldnew)
{
int len;
const char *name;
if (!orig_name && !isnull)
return find_name(line, NULL, 1, 0);
name = "/dev/null";
len = 9;
if (orig_name) {
name = orig_name;
len = strlen(name);
if (isnull)
die("git-apply: bad git-diff - expected /dev/null, got %s on line %d", name, linenr);
}
if (*name == '/')
goto absolute_path;
for (;;) {
char c = *line++;
if (c == '\n')
break;
if (c != '/')
continue;
absolute_path:
if (memcmp(line, name, len) || line[len] != '\n')
break;
return orig_name;
}
die("git-apply: bad git-diff - inconsistent %s filename on line %d", oldnew, linenr);
return NULL;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_oldname(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->old_name = gitdiff_verify_name(line, patch->is_new, patch->old_name, "old");
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
return 0;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_newname(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->new_name = gitdiff_verify_name(line, patch->is_delete, patch->new_name, "new");
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
return 0;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_oldmode(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->old_mode = strtoul(line, NULL, 8);
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
return 0;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_newmode(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->new_mode = strtoul(line, NULL, 8);
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
return 0;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_delete(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->is_delete = 1;
git-apply: pick up default filenames from "diff --git" header line Pure mode changes, and deletes or creates of empty files won't have this information anywhere else.
2005-05-26 22:11:24 +02:00
patch->old_name = patch->def_name;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
return gitdiff_oldmode(line, patch);
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_newfile(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->is_new = 1;
git-apply: pick up default filenames from "diff --git" header line Pure mode changes, and deletes or creates of empty files won't have this information anywhere else.
2005-05-26 22:11:24 +02:00
patch->new_name = patch->def_name;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
return gitdiff_newmode(line, patch);
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_copysrc(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->is_copy = 1;
patch->old_name = find_name(line, NULL, 0, 0);
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
return 0;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_copydst(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->is_copy = 1;
patch->new_name = find_name(line, NULL, 0, 0);
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
return 0;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_renamesrc(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->is_rename = 1;
patch->old_name = find_name(line, NULL, 0, 0);
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
return 0;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_renamedst(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->is_rename = 1;
patch->new_name = find_name(line, NULL, 0, 0);
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
return 0;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_similarity(const char *line, struct patch *patch)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{
return 0;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
}
[PATCH] Show dissimilarity index for D and N case. The way broken deletes and creates are shown in the -p (diff-patch) output format has become consistent with how rename/copy edits are shown. They will show "dissimilarity index" value, immediately following the "deleted file mode" and "new file mode" lines. The git-apply is taught to grok such an extended header. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-05-31 01:40:16 +02:00
static int gitdiff_dissimilarity(const char *line, struct patch *patch)
{
return 0;
}
git-apply: start using the index file information. Right now we only use it to figure out what the filename might be when that is ambiguous, but we'll get there..
2005-05-24 04:13:55 +02:00
/*
* This is normal for a diff that doesn't change anything: we'll fall through
* into the next diff. Tell the parser to break out.
*/
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int gitdiff_unrecognized(const char *line, struct patch *patch)
git-apply: start using the index file information. Right now we only use it to figure out what the filename might be when that is ambiguous, but we'll get there..
2005-05-24 04:13:55 +02:00
{
return -1;
}
git-apply: pick up default filenames from "diff --git" header line Pure mode changes, and deletes or creates of empty files won't have this information anywhere else.
2005-05-26 22:11:24 +02:00
static char *git_header_name(char *line)
{
int len;
char *name, *second;
/*
* Find the first '/'
*/
name = line;
for (;;) {
char c = *name++;
if (c == '\n')
return NULL;
if (c == '/')
break;
}
/*
* We don't accept absolute paths (/dev/null) as possibly valid
*/
if (name == line+1)
return NULL;
/*
* Accept a name only if it shows up twice, exactly the same
* form.
*/
for (len = 0 ; ; len++) {
char c = name[len];
switch (c) {
default:
continue;
case '\n':
break;
case '\t': case ' ':
second = name+len;
for (;;) {
char c = *second++;
if (c == '\n')
return NULL;
if (c == '/')
break;
}
git-apply: when validating default names, check the final EOLN too This means that filenames are totally unambiguous even if they have spaces or tabs in them.
2005-05-26 22:28:42 +02:00
if (second[len] == '\n' && !memcmp(name, second, len)) {
git-apply: pick up default filenames from "diff --git" header line Pure mode changes, and deletes or creates of empty files won't have this information anywhere else.
2005-05-26 22:11:24 +02:00
char *ret = xmalloc(len + 1);
memcpy(ret, name, len);
ret[len] = 0;
return ret;
}
}
}
return NULL;
}
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
/* Verify that we recognize the lines following a git header */
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int parse_git_header(char *line, int len, unsigned int size, struct patch *patch)
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
{
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
unsigned long offset;
/* A git diff has explicit new/delete information, so we don't guess */
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->is_new = 0;
patch->is_delete = 0;
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
git-apply: pick up default filenames from "diff --git" header line Pure mode changes, and deletes or creates of empty files won't have this information anywhere else.
2005-05-26 22:11:24 +02:00
/*
* Some things may not have the old name in the
* rest of the headers anywhere (pure mode changes,
* or removing or adding empty files), so we get
* the default name from the header.
*/
patch->def_name = git_header_name(line + strlen("diff --git "));
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
line += len;
size -= len;
linenr++;
for (offset = len ; size > 0 ; offset += len, size -= len, line += len, linenr++) {
static const struct opentry {
const char *str;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
int (*fn)(const char *, struct patch *);
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
} optable[] = {
{ "@@ -", gitdiff_hdrend },
{ "--- ", gitdiff_oldname },
{ "+++ ", gitdiff_newname },
{ "old mode ", gitdiff_oldmode },
{ "new mode ", gitdiff_newmode },
{ "deleted file mode ", gitdiff_delete },
{ "new file mode ", gitdiff_newfile },
{ "copy from ", gitdiff_copysrc },
{ "copy to ", gitdiff_copydst },
git-apply: fix rename header parsing It's not "rename from" and "rename to", it's "rename old" and "rename new". Which is illogical and doesn't match the "copy from/to" case, but that's life. Maybe Junio will fix it up one of these days.
2005-06-05 23:26:50 +02:00
{ "rename old ", gitdiff_renamesrc },
{ "rename new ", gitdiff_renamedst },
diff 'rename' format change. Clearly even Junio felt git "rename" header lines should say "from/to" instead of "old/new", since he wrote the documentation that way. This way it also matches "copy". git-apply will accept both versions, at least for a while.
2005-06-06 00:31:52 +02:00
{ "rename from ", gitdiff_renamesrc },
{ "rename to ", gitdiff_renamedst },
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
{ "similarity index ", gitdiff_similarity },
[PATCH] Show dissimilarity index for D and N case. The way broken deletes and creates are shown in the -p (diff-patch) output format has become consistent with how rename/copy edits are shown. They will show "dissimilarity index" value, immediately following the "deleted file mode" and "new file mode" lines. The git-apply is taught to grok such an extended header. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-05-31 01:40:16 +02:00
{ "dissimilarity index ", gitdiff_dissimilarity },
git-apply: start using the index file information. Right now we only use it to figure out what the filename might be when that is ambiguous, but we'll get there..
2005-05-24 04:13:55 +02:00
{ "", gitdiff_unrecognized },
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
};
int i;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
len = linelen(line, size);
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
if (!len || line[len-1] != '\n')
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
break;
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
for (i = 0; i < sizeof(optable) / sizeof(optable[0]); i++) {
const struct opentry *p = optable + i;
int oplen = strlen(p->str);
if (len < oplen || memcmp(p->str, line, oplen))
continue;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
if (p->fn(line + oplen, patch) < 0)
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
return offset;
git-apply: start using the index file information. Right now we only use it to figure out what the filename might be when that is ambiguous, but we'll get there..
2005-05-24 04:13:55 +02:00
break;
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
}
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
}
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
return offset;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
}
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
static int parse_num(const char *line, unsigned long *p)
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
{
char *ptr;
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
if (!isdigit(*line))
return 0;
*p = strtoul(line, &ptr, 10);
return ptr - line;
}
static int parse_range(const char *line, int len, int offset, const char *expect,
unsigned long *p1, unsigned long *p2)
{
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
int digits, ex;
if (offset < 0 || offset >= len)
return -1;
line += offset;
len -= offset;
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
digits = parse_num(line, p1);
if (!digits)
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
return -1;
offset += digits;
line += digits;
len -= digits;
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
*p2 = *p1;
if (*line == ',') {
digits = parse_num(line+1, p2);
if (!digits)
return -1;
offset += digits+1;
line += digits+1;
len -= digits+1;
}
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
ex = strlen(expect);
if (ex > len)
return -1;
if (memcmp(line, expect, ex))
return -1;
return offset + ex;
}
/*
* Parse a unified diff fragment header of the
* form "@@ -a,b +c,d @@"
*/
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int parse_fragment_header(char *line, int len, struct fragment *fragment)
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
{
int offset;
if (!len || line[len-1] != '\n')
return -1;
/* Figure out the number of lines in a fragment */
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
offset = parse_range(line, len, 4, " +", &fragment->oldpos, &fragment->oldlines);
offset = parse_range(line, len, offset, " @@", &fragment->newpos, &fragment->newlines);
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
return offset;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int find_header(char *line, unsigned long size, int *hdrsize, struct patch *patch)
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
{
unsigned long offset, len;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patch->is_rename = patch->is_copy = 0;
patch->is_new = patch->is_delete = -1;
patch->old_mode = patch->new_mode = 0;
patch->old_name = patch->new_name = NULL;
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
for (offset = 0; size > 0; offset += len, size -= len, line += len, linenr++) {
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
unsigned long nextlen;
len = linelen(line, size);
if (!len)
break;
/* Testing this early allows us to take a few shortcuts.. */
if (len < 6)
continue;
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
/*
* Make sure we don't find any unconnected patch fragmants.
* That's a sign that we didn't find a header, and that a
* patch has become corrupted/broken up.
*/
if (!memcmp("@@ -", line, 4)) {
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
struct fragment dummy;
if (parse_fragment_header(line, len, &dummy) < 0)
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
continue;
error("patch fragment without header at line %d: %.*s", linenr, len-1, line);
}
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
if (size < len + 6)
break;
/*
* Git patch? It might not have a real patch, just a rename
* or mode change, so we handle that specially
*/
if (!memcmp("diff --git ", line, 11)) {
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
int git_hdr_len = parse_git_header(line, len, size, patch);
git-apply: ignore empty git headers A meaningful (ie non-empty) git patch always has more information in the header than just the "diff --git" line itself: it needs to have either a patch associated with it (which implies "---" and "+++" lines in the header) or it needs to have rename/copy/delete/create information in it. Just ignore git patches which have no change information. Otherwise we'll end up with a patch that doesn't have filenames etc filled in, and we'll be unhappy.
2005-06-12 18:37:49 +02:00
if (git_hdr_len <= len)
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
continue;
git-apply: use default name for mode change patches Pure mode changes won't have the file-name in the extended header lines, so make sure we pick it up from the default name from the "diff --git" line.
2005-06-18 00:23:40 +02:00
if (!patch->old_name && !patch->new_name) {
if (!patch->def_name)
die("git diff header lacks filename information (line %d)", linenr);
patch->old_name = patch->new_name = patch->def_name;
}
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
*hdrsize = git_hdr_len;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
return offset;
}
/** --- followed by +++ ? */
if (memcmp("--- ", line, 4) || memcmp("+++ ", line + len, 4))
continue;
/*
* We only accept unified patches, so we want it to
* at least have "@@ -a,b +c,d @@\n", which is 14 chars
* minimum
*/
nextlen = linelen(line + len, size - len);
if (size < nextlen + 14 || memcmp("@@ -", line + len + nextlen, 4))
continue;
/* Ok, we'll consider it a patch */
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
parse_traditional_patch(line, line+len, patch);
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
*hdrsize = len + nextlen;
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
linenr += 2;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
return offset;
}
return -1;
}
/*
* Parse a unified diff. Note that this really needs
* to parse each fragment separately, since the only
* way to know the difference between a "---" that is
* part of a patch, and a "---" that starts the next
* patch is to look at the line counts..
*/
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int parse_fragment(char *line, unsigned long size, struct patch *patch, struct fragment *fragment)
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
{
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
int added, deleted;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
int len = linelen(line, size), offset;
git-apply: fix apply of a new file (And fix name handling for when we have an implied create or delete event from a traditional diff).
2005-06-05 21:43:56 +02:00
unsigned long oldlines, newlines;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
offset = parse_fragment_header(line, len, fragment);
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
if (offset < 0)
return -1;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
oldlines = fragment->oldlines;
newlines = fragment->newlines;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
git-apply: fix apply of a new file (And fix name handling for when we have an implied create or delete event from a traditional diff).
2005-06-05 21:43:56 +02:00
if (patch->is_new < 0) {
patch->is_new = !oldlines;
if (!oldlines)
patch->old_name = NULL;
}
if (patch->is_delete < 0) {
patch->is_delete = !newlines;
if (!newlines)
patch->new_name = NULL;
}
if (patch->is_new != !oldlines)
return error("new file depends on old contents");
git-apply: creatign empty files is nonfatal (but it will result in a warning)
2005-06-08 17:11:47 +02:00
if (patch->is_delete != !newlines) {
if (newlines)
return error("deleted file still has contents");
fprintf(stderr, "** warning: file %s becomes empty but is not deleted\n", patch->new_name);
}
git-apply: parse the diff headers (both traditional and new) .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
2005-05-24 01:09:09 +02:00
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
/* Parse the thing.. */
line += len;
size -= len;
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
linenr++;
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
added = deleted = 0;
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
for (offset = len; size > 0; offset += len, size -= len, line += len, linenr++) {
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
if (!oldlines && !newlines)
break;
len = linelen(line, size);
if (!len || line[len-1] != '\n')
return -1;
switch (*line) {
default:
return -1;
case ' ':
oldlines--;
newlines--;
break;
case '-':
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
deleted++;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
oldlines--;
break;
case '+':
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
added++;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
newlines--;
break;
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
/* We allow "\ No newline at end of file" */
case '\\':
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
if (len < 12 || memcmp(line, "\\ No newline", 12))
return -1;
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
break;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
}
}
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
patch->lines_added += added;
patch->lines_deleted += deleted;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
return offset;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int parse_single_patch(char *line, unsigned long size, struct patch *patch)
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
{
unsigned long offset = 0;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
struct fragment **fragp = &patch->fragments;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
while (size > 4 && !memcmp(line, "@@ -", 4)) {
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
struct fragment *fragment;
int len;
fragment = xmalloc(sizeof(*fragment));
memset(fragment, 0, sizeof(*fragment));
len = parse_fragment(line, size, patch, fragment);
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
if (len <= 0)
git-apply: improve error detection and messages In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
2005-05-23 23:38:49 +02:00
die("corrupt patch at line %d", linenr);
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
fragment->patch = line;
fragment->size = len;
*fragp = fragment;
fragp = &fragment->next;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
offset += len;
line += len;
size -= len;
}
return offset;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
static int parse_chunk(char *buffer, unsigned long size, struct patch *patch)
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
{
int hdrsize, patchsize;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
int offset = find_header(buffer, size, &hdrsize, patch);
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
if (offset < 0)
return offset;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
patchsize = parse_single_patch(buffer + offset + hdrsize, size - offset - hdrsize, patch);
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
return offset + hdrsize + patchsize;
}
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
const char pluses[] = "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++";
const char minuses[]= "----------------------------------------------------------------------";
static void show_stats(struct patch *patch)
{
char *name = patch->old_name;
git-apply --stat: limit lines to 79 characters It had already tried to do that, but with the independent rounding of the number of '+' and '-' characters, it would sometimes do 80-char lines after all.
2005-06-01 05:50:49 +02:00
int len, max, add, del, total;
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
git-apply: pick up default filenames from "diff --git" header line Pure mode changes, and deletes or creates of empty files won't have this information anywhere else.
2005-05-26 22:11:24 +02:00
if (!name)
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
name = patch->new_name;
/*
* "scale" the filename
*/
len = strlen(name);
max = max_len;
if (max > 50)
max = 50;
if (len > max)
name += len - max;
len = max;
/*
* scale the add/delete
*/
max = max_change;
if (max + len > 70)
max = 70 - len;
git-apply --stat: limit lines to 79 characters It had already tried to do that, but with the independent rounding of the number of '+' and '-' characters, it would sometimes do 80-char lines after all.
2005-06-01 05:50:49 +02:00
add = patch->lines_added;
del = patch->lines_deleted;
total = add + del;
total = (total * max + max_change / 2) / max_change;
add = (add * max + max_change / 2) / max_change;
del = total - add;
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
printf(" %-*s |%5d %.*s%.*s\n",
len, name, patch->lines_added + patch->lines_deleted,
add, pluses, del, minuses);
}
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
static int read_old_data(struct stat *st, const char *path, void *buf, unsigned long size)
{
int fd;
unsigned long got;
switch (st->st_mode & S_IFMT) {
case S_IFLNK:
return readlink(path, buf, size);
case S_IFREG:
fd = open(path, O_RDONLY);
if (fd < 0)
return error("unable to open %s", path);
got = 0;
for (;;) {
int ret = read(fd, buf + got, size - got);
if (ret < 0) {
if (errno == EAGAIN)
continue;
break;
}
if (!ret)
break;
got += ret;
}
close(fd);
return got;
default:
return -1;
}
}
static int find_offset(const char *buf, unsigned long size, const char *fragment, unsigned long fragsize, int line)
{
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
int i;
unsigned long start, backwards, forwards;
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
if (fragsize > size)
return -1;
start = 0;
if (line > 1) {
unsigned long offset = 0;
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
i = line-1;
while (offset + fragsize <= size) {
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
if (buf[offset++] == '\n') {
start = offset;
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
if (!--i)
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
break;
}
}
}
/* Exact line number? */
if (!memcmp(buf + start, fragment, fragsize))
return start;
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
/*
* There's probably some smart way to do this, but I'll leave
* that to the smart and beautiful people. I'm simple and stupid.
*/
backwards = start;
forwards = start;
for (i = 0; ; i++) {
unsigned long try;
int n;
/* "backward" */
if (i & 1) {
if (!backwards) {
if (forwards + fragsize > size)
break;
continue;
}
do {
--backwards;
} while (backwards && buf[backwards-1] != '\n');
try = backwards;
} else {
while (forwards + fragsize <= size) {
if (buf[forwards++] == '\n')
break;
}
try = forwards;
}
if (try + fragsize > size)
continue;
if (memcmp(buf + try, fragment, fragsize))
continue;
n = (i >> 1)+1;
if (i & 1)
n = -n;
fprintf(stderr, "Fragment applied at offset %d\n", n);
return try;
}
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
/*
* We should start searching forward and backward.
*/
return -1;
}
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
struct buffer_desc {
char *buffer;
unsigned long size;
unsigned long alloc;
};
static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag)
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
{
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
char *buf = desc->buffer;
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
const char *patch = frag->patch;
int offset, size = frag->size;
char *old = xmalloc(size);
char *new = xmalloc(size);
int oldsize = 0, newsize = 0;
while (size > 0) {
int len = linelen(patch, size);
int plen;
if (!len)
break;
/*
* "plen" is how much of the line we should use for
* the actual patch data. Normally we just remove the
* first character on the line, but if the line is
* followed by "\ No newline", then we also remove the
* last one (which is the newline, of course).
*/
plen = len-1;
if (len > size && patch[len] == '\\')
plen--;
switch (*patch) {
case ' ':
case '-':
memcpy(old + oldsize, patch + 1, plen);
oldsize += plen;
if (*patch == '-')
break;
/* Fall-through for ' ' */
case '+':
memcpy(new + newsize, patch + 1, plen);
newsize += plen;
break;
case '@': case '\\':
/* Ignore it, we already handled it */
break;
default:
return -1;
}
patch += len;
size -= len;
}
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
offset = find_offset(buf, desc->size, old, oldsize, frag->newpos);
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
if (offset >= 0) {
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
int diff = newsize - oldsize;
unsigned long size = desc->size + diff;
unsigned long alloc = desc->alloc;
if (size > alloc) {
alloc = size + 8192;
desc->alloc = alloc;
buf = xrealloc(buf, alloc);
desc->buffer = buf;
}
desc->size = size;
memmove(buf + offset + newsize, buf + offset + oldsize, size - offset - newsize);
memcpy(buf + offset, new, newsize);
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
offset = 0;
}
free(old);
free(new);
return offset;
}
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
static int apply_fragments(struct buffer_desc *desc, struct patch *patch)
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
{
struct fragment *frag = patch->fragments;
while (frag) {
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
if (apply_one_fragment(desc, frag) < 0)
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
return error("patch failed: %s:%d", patch->old_name, frag->oldpos);
frag = frag->next;
}
git-apply: fix apply of a new file (And fix name handling for when we have an implied create or delete event from a traditional diff).
2005-06-05 21:43:56 +02:00
return 0;
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
}
static int apply_data(struct patch *patch, struct stat *st)
{
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
char *buf;
unsigned long size, alloc;
struct buffer_desc desc;
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
git-apply: fix apply of a new file (And fix name handling for when we have an implied create or delete event from a traditional diff).
2005-06-05 21:43:56 +02:00
size = 0;
alloc = 0;
buf = NULL;
if (patch->old_name) {
size = st->st_size;
alloc = size + 8192;
buf = xmalloc(alloc);
if (read_old_data(st, patch->old_name, buf, alloc) != size)
return error("read of %s failed", patch->old_name);
}
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
desc.size = size;
desc.alloc = alloc;
desc.buffer = buf;
if (apply_fragments(&desc, patch) < 0)
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
return -1;
git-apply: find offset fragments, and really apply them This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
2005-06-05 21:16:32 +02:00
patch->result = desc.buffer;
patch->resultsize = desc.size;
git-apply: actually apply patches and update the index We update the index only if the "--index" flag is given, so you can actually use this as a strange kind of "patch" program even for non-git usage. Not that you'd likely want to, but it comes in handy for testing. This _should_ more or less get everythign right, but as usual I leave the testing to the usrs..
2005-06-05 23:05:43 +02:00
if (patch->is_delete && patch->resultsize)
return error("removal patch leaves file contents");
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
return 0;
}
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
static int check_patch(struct patch *patch)
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
{
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
struct stat st;
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
const char *old_name = patch->old_name;
const char *new_name = patch->new_name;
if (old_name) {
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
int changed;
if (lstat(old_name, &st) < 0)
git-apply: fix error handling for nonexistent files Missing argument for error() function. We should really use the gcc printf format checking capabilities.
2005-06-13 06:04:27 +02:00
return error("%s: %s", old_name, strerror(errno));
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
if (check_index) {
int pos = cache_name_pos(old_name, strlen(old_name));
if (pos < 0)
return error("%s: does not exist in index", old_name);
changed = ce_match_stat(active_cache[pos], &st);
if (changed)
return error("%s: does not match index", old_name);
}
if (patch->is_new < 0)
patch->is_new = 0;
git-apply: normalize file mode when comparing with expected value Sine git only saves the 'x' bit, we shouldn't compare the stat contents directly.
2005-06-14 05:41:38 +02:00
st.st_mode = ntohl(create_ce_mode(st.st_mode));
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
if (!patch->old_mode)
patch->old_mode = st.st_mode;
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
if ((st.st_mode ^ patch->old_mode) & S_IFMT)
return error("%s: wrong type", old_name);
if (st.st_mode != patch->old_mode)
fprintf(stderr, "warning: %s has type %o, expected %o\n",
old_name, st.st_mode, patch->old_mode);
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
}
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
if (new_name && (patch->is_new | patch->is_rename | patch->is_copy)) {
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
if (check_index && cache_name_pos(new_name, strlen(new_name)) >= 0)
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
return error("%s: already exists in index", new_name);
if (!lstat(new_name, &st))
return error("%s: already exists in working directory", new_name);
if (errno != ENOENT)
return error("%s: %s", new_name, strerror(errno));
git-apply: actually apply patches and update the index We update the index only if the "--index" flag is given, so you can actually use this as a strange kind of "patch" program even for non-git usage. Not that you'd likely want to, but it comes in handy for testing. This _should_ more or less get everythign right, but as usual I leave the testing to the usrs..
2005-06-05 23:05:43 +02:00
if (!patch->new_mode)
patch->new_mode = S_IFREG | 0644;
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
}
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
if (new_name && old_name) {
int same = !strcmp(old_name, new_name);
if (!patch->new_mode)
patch->new_mode = patch->old_mode;
if ((patch->old_mode ^ patch->new_mode) & S_IFMT)
return error("new mode (%o) of %s does not match old mode (%o)%s%s",
patch->new_mode, new_name, patch->old_mode,
same ? "" : " of ", same ? "" : old_name);
}
if (apply_data(patch, &st) < 0)
return error("%s: patch does not apply", old_name);
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
return 0;
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
}
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
static int check_patch_list(struct patch *patch)
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
{
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
int error = 0;
for (;patch ; patch = patch->next)
error |= check_patch(patch);
return error;
}
static void show_file(int c, unsigned int mode, const char *name)
{
printf("%c %o %s\n", c, mode, name);
}
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
static void show_file_list(struct patch *patch)
{
for (;patch ; patch = patch->next) {
if (patch->is_rename) {
show_file('-', patch->old_mode, patch->old_name);
show_file('+', patch->new_mode, patch->new_name);
continue;
}
if (patch->is_copy || patch->is_new) {
show_file('+', patch->new_mode, patch->new_name);
continue;
}
if (patch->is_delete) {
show_file('-', patch->old_mode, patch->old_name);
continue;
}
if (patch->old_mode && patch->new_mode && patch->old_mode != patch->new_mode) {
printf("M %o:%o %s\n", patch->old_mode, patch->new_mode, patch->old_name);
continue;
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
}
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
printf("M %o %s\n", patch->old_mode, patch->old_name);
}
}
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
static void stat_patch_list(struct patch *patch)
{
int files, adds, dels;
for (files = adds = dels = 0 ; patch ; patch = patch->next) {
files++;
adds += patch->lines_added;
dels += patch->lines_deleted;
show_stats(patch);
}
printf(" %d files changed, %d insertions(+), %d deletions(-)\n", files, adds, dels);
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
}
static void patch_stats(struct patch *patch)
{
int lines = patch->lines_added + patch->lines_deleted;
if (lines > max_change)
max_change = lines;
if (patch->old_name) {
int len = strlen(patch->old_name);
if (len > max_len)
max_len = len;
}
if (patch->new_name) {
int len = strlen(patch->new_name);
if (len > max_len)
max_len = len;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
}
git-apply: actually apply patches and update the index We update the index only if the "--index" flag is given, so you can actually use this as a strange kind of "patch" program even for non-git usage. Not that you'd likely want to, but it comes in handy for testing. This _should_ more or less get everythign right, but as usual I leave the testing to the usrs..
2005-06-05 23:05:43 +02:00
static void remove_file(struct patch *patch)
{
if (write_index) {
if (remove_file_from_cache(patch->old_name) < 0)
die("unable to remove %s from index", patch->old_name);
}
unlink(patch->old_name);
}
static void add_index_file(const char *path, unsigned mode, void *buf, unsigned long size)
{
struct stat st;
struct cache_entry *ce;
int namelen = strlen(path);
unsigned ce_size = cache_entry_size(namelen);
if (!write_index)
return;
ce = xmalloc(ce_size);
memset(ce, 0, ce_size);
memcpy(ce->name, path, namelen);
ce->ce_mode = create_ce_mode(mode);
ce->ce_flags = htons(namelen);
if (lstat(path, &st) < 0)
die("unable to stat newly created file %s", path);
fill_stat_cache_info(ce, &st);
if (write_sha1_file(buf, size, "blob", ce->sha1) < 0)
die("unable to create backing store for newly created file %s", path);
if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD) < 0)
die("unable to add cache entry for %s", path);
}
static void create_file(struct patch *patch)
{
const char *path = patch->new_name;
unsigned mode = patch->new_mode;
unsigned long size = patch->resultsize;
char *buf = patch->result;
if (!mode)
mode = S_IFREG | 0644;
if (S_ISREG(mode)) {
int fd;
mode = (mode & 0100) ? 0777 : 0666;
fd = open(path, O_WRONLY | O_CREAT | O_TRUNC, mode);
if (fd < 0)
die("unable to create file %s (%s)", path, strerror(errno));
if (write(fd, buf, size) != size)
die("unable to write file %s", path);
close(fd);
add_index_file(path, mode, buf, size);
return;
}
if (S_ISLNK(mode)) {
if (size && buf[size-1] == '\n')
size--;
buf[size] = 0;
if (symlink(buf, path) < 0)
die("unable to write symlink %s", path);
add_index_file(path, mode, buf, size);
return;
}
die("unable to write file mode %o", mode);
}
static void write_out_one_result(struct patch *patch)
{
if (patch->is_delete > 0) {
remove_file(patch);
return;
}
if (patch->is_new > 0 || patch->is_copy) {
create_file(patch);
return;
}
/*
* Rename or modification boils down to the same
* thing: remove the old, write the new
*/
remove_file(patch);
create_file(patch);
}
static void write_out_results(struct patch *list)
{
git-apply: consider it an error to apply no changes A "--stat" or a "--check" will just be quiet, but if you try to apply something with no changes, that's an error.
2005-06-06 00:25:28 +02:00
if (!list)
die("No changes");
git-apply: actually apply patches and update the index We update the index only if the "--index" flag is given, so you can actually use this as a strange kind of "patch" program even for non-git usage. Not that you'd likely want to, but it comes in handy for testing. This _should_ more or less get everythign right, but as usual I leave the testing to the usrs..
2005-06-05 23:05:43 +02:00
while (list) {
write_out_one_result(list);
list = list->next;
}
}
static struct cache_file cache_file;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
static int apply_patch(int fd)
{
git-apply: actually apply patches and update the index We update the index only if the "--index" flag is given, so you can actually use this as a strange kind of "patch" program even for non-git usage. Not that you'd likely want to, but it comes in handy for testing. This _should_ more or less get everythign right, but as usual I leave the testing to the usrs..
2005-06-05 23:05:43 +02:00
int newfd;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
unsigned long offset, size;
char *buffer = read_patch_file(fd, &size);
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
struct patch *list = NULL, **listp = &list;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
if (!buffer)
return -1;
offset = 0;
while (size > 0) {
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
struct patch *patch;
int nr;
patch = xmalloc(sizeof(*patch));
memset(patch, 0, sizeof(*patch));
nr = parse_chunk(buffer + offset, size, patch);
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
if (nr < 0)
break;
git-apply: implement "diffstat" output Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
2005-05-26 20:40:43 +02:00
patch_stats(patch);
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
*listp = patch;
listp = &patch->next;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
offset += nr;
size -= nr;
}
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
git-apply: actually apply patches and update the index We update the index only if the "--index" flag is given, so you can actually use this as a strange kind of "patch" program even for non-git usage. Not that you'd likely want to, but it comes in handy for testing. This _should_ more or less get everythign right, but as usual I leave the testing to the usrs..
2005-06-05 23:05:43 +02:00
newfd = -1;
write_index = check_index && apply;
if (write_index)
newfd = hold_index_file_for_update(&cache_file, get_index_file());
if (check_index) {
if (read_cache() < 0)
die("unable to read index file");
}
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
if ((check || apply) && check_patch_list(list) < 0)
exit(1);
git-apply: actually apply patches and update the index We update the index only if the "--index" flag is given, so you can actually use this as a strange kind of "patch" program even for non-git usage. Not that you'd likely want to, but it comes in handy for testing. This _should_ more or less get everythign right, but as usual I leave the testing to the usrs..
2005-06-05 23:05:43 +02:00
if (apply)
write_out_results(list);
if (write_index) {
if (write_cache(newfd, active_cache, active_nr) ||
commit_index_file(&cache_file))
die("Unable to write new cachefile");
}
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
if (show_files)
show_file_list(list);
if (diffstat)
stat_patch_list(list);
git-apply: parse the whole list of patches into memory first Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
2005-05-26 19:23:51 +02:00
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
free(buffer);
return 0;
}
int main(int argc, char **argv)
{
int i;
git-apply: if no input files specified, apply stdin This makes it act more like a traditional UNIX thing (eg "cat").
2005-05-24 01:42:21 +02:00
int read_stdin = 1;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
int fd;
if (!strcmp(arg, "-")) {
apply_patch(0);
git-apply: if no input files specified, apply stdin This makes it act more like a traditional UNIX thing (eg "cat").
2005-05-24 01:42:21 +02:00
read_stdin = 0;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
continue;
}
if (!strcmp(arg, "--no-merge")) {
merge_patch = 0;
continue;
}
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
if (!strcmp(arg, "--stat")) {
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
apply = 0;
git-apply: make the diffstat output happen for "--stat" only. Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
2005-05-26 21:25:52 +02:00
diffstat = 1;
continue;
}
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
if (!strcmp(arg, "--check")) {
apply = 0;
check = 1;
continue;
}
git-apply: first cut at actually checking fragment data Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
2005-06-05 20:03:13 +02:00
if (!strcmp(arg, "--index")) {
check_index = 1;
continue;
}
git-apply: add "--check" option to check that the diff makes sense It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
2005-05-27 00:10:02 +02:00
if (!strcmp(arg, "--show-files")) {
show_files = 1;
continue;
}
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
fd = open(arg, O_RDONLY);
if (fd < 0)
usage(apply_usage);
git-apply: if no input files specified, apply stdin This makes it act more like a traditional UNIX thing (eg "cat").
2005-05-24 01:42:21 +02:00
read_stdin = 0;
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
apply_patch(fd);
close(fd);
}
git-apply: if no input files specified, apply stdin This makes it act more like a traditional UNIX thing (eg "cat").
2005-05-24 01:42:21 +02:00
if (read_stdin)
apply_patch(0);
Start implementing "git-apply" This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
2005-05-23 19:52:17 +02:00
return 0;
}
Copy permalink