1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-18 15:04:49 +01:00
git/merge-tree.c

273 lines
6.3 KiB
C
Raw Normal View History

Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
#include "cache.h"
#include "diff.h"
static const char merge_tree_usage[] = "git-merge-tree <base-tree> <branch1> <branch2>";
static int resolve_directories = 1;
static void merge_trees(struct tree_desc t[3], const char *base);
static void *fill_tree_descriptor(struct tree_desc *desc, const unsigned char *sha1)
{
unsigned long size = 0;
void *buf = NULL;
if (sha1) {
buf = read_object_with_reference(sha1, "tree", &size, NULL);
if (!buf)
die("unable to read tree %s", sha1_to_hex(sha1));
}
desc->size = size;
desc->buf = buf;
return buf;
}
struct name_entry {
const unsigned char *sha1;
const char *path;
unsigned int mode;
int pathlen;
};
static void entry_clear(struct name_entry *a)
{
memset(a, 0, sizeof(*a));
}
static int entry_compare(struct name_entry *a, struct name_entry *b)
{
return base_name_compare(
a->path, a->pathlen, a->mode,
b->path, b->pathlen, b->mode);
}
static void entry_extract(struct tree_desc *t, struct name_entry *a)
{
a->sha1 = tree_entry_extract(t, &a->path, &a->mode);
a->pathlen = strlen(a->path);
}
/* An empty entry never compares same, not even to another empty entry */
static int same_entry(struct name_entry *a, struct name_entry *b)
{
return a->sha1 &&
b->sha1 &&
!memcmp(a->sha1, b->sha1, 20) &&
a->mode == b->mode;
}
static const char *sha1_to_hex_zero(const unsigned char *sha1)
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
{
if (sha1)
return sha1_to_hex(sha1);
return "0000000000000000000000000000000000000000";
}
static void resolve(const char *base, struct name_entry *branch1, struct name_entry *result)
{
char branch1_sha1[50];
/* If it's already branch1, don't bother showing it */
if (!branch1)
return;
memcpy(branch1_sha1, sha1_to_hex_zero(branch1->sha1), 41);
printf("0 %06o->%06o %s->%s %s%s\n",
branch1->mode, result->mode,
branch1_sha1, sha1_to_hex_zero(result->sha1),
base, result->path);
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
}
static int unresolved_directory(const char *base, struct name_entry n[3])
{
int baselen;
char *newbase;
struct name_entry *p;
struct tree_desc t[3];
void *buf0, *buf1, *buf2;
if (!resolve_directories)
return 0;
p = n;
if (!p->mode) {
p++;
if (!p->mode)
p++;
}
if (!S_ISDIR(p->mode))
return 0;
baselen = strlen(base);
newbase = xmalloc(baselen + p->pathlen + 2);
memcpy(newbase, base, baselen);
memcpy(newbase + baselen, p->path, p->pathlen);
memcpy(newbase + baselen + p->pathlen, "/", 2);
buf0 = fill_tree_descriptor(t+0, n[0].sha1);
buf1 = fill_tree_descriptor(t+1, n[1].sha1);
buf2 = fill_tree_descriptor(t+2, n[2].sha1);
merge_trees(t, newbase);
free(buf0);
free(buf1);
free(buf2);
free(newbase);
return 1;
}
static void unresolved(const char *base, struct name_entry n[3])
{
if (unresolved_directory(base, n))
return;
if (n[0].sha1)
printf("1 %06o %s %s%s\n", n[0].mode, sha1_to_hex(n[0].sha1), base, n[0].path);
if (n[1].sha1)
printf("2 %06o %s %s%s\n", n[1].mode, sha1_to_hex(n[1].sha1), base, n[1].path);
if (n[2].sha1)
printf("3 %06o %s %s%s\n", n[2].mode, sha1_to_hex(n[2].sha1), base, n[2].path);
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
}
typedef void (*traverse_callback_t)(int n, unsigned long mask, struct name_entry *entry, const char *base);
static void traverse_trees(int n, struct tree_desc *t, const char *base, traverse_callback_t callback)
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
{
struct name_entry *entry = xmalloc(n*sizeof(*entry));
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
for (;;) {
struct name_entry entry[3];
unsigned long mask = 0;
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
int i, last;
last = -1;
for (i = 0; i < n; i++) {
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
if (!t[i].size)
continue;
entry_extract(t+i, entry+i);
if (last >= 0) {
int cmp = entry_compare(entry+i, entry+last);
/*
* Is the new name bigger than the old one?
* Ignore it
*/
if (cmp > 0)
continue;
/*
* Is the new name smaller than the old one?
* Ignore all old ones
*/
if (cmp < 0)
mask = 0;
}
mask |= 1ul << i;
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
last = i;
}
if (!mask)
break;
/*
* Update the tree entries we've walked, and clear
* all the unused name-entries.
*/
for (i = 0; i < n; i++) {
if (mask & (1ul << i)) {
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
update_tree_entry(t+i);
continue;
}
entry_clear(entry + i);
}
callback(n, mask, entry, base);
}
free(entry);
}
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
/*
* Merge two trees together (t[1] and t[2]), using a common base (t[0])
* as the origin.
*
* This walks the (sorted) trees in lock-step, checking every possible
* name. Note that directories automatically sort differently from other
* files (see "base_name_compare"), so you'll never see file/directory
* conflicts, because they won't ever compare the same.
*
* IOW, if a directory changes to a filename, it will automatically be
* seen as the directory going away, and the filename being created.
*
* Think of this as a three-way diff.
*
* The output will be either:
* - successful merge
* "0 mode sha1 filename"
* NOTE NOTE NOTE! FIXME! We really really need to walk the index
* in parallel with this too!
*
* - conflict:
* "1 mode sha1 filename"
* "2 mode sha1 filename"
* "3 mode sha1 filename"
* where not all of the 1/2/3 lines may exist, of course.
*
* The successful merge rules are the same as for the three-way merge
* in git-read-tree.
*/
static void threeway_callback(int n, unsigned long mask, struct name_entry *entry, const char *base)
{
/* Same in both? */
if (same_entry(entry+1, entry+2)) {
if (entry[0].sha1) {
resolve(base, NULL, entry+1);
return;
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
}
}
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
if (same_entry(entry+0, entry+1)) {
if (entry[2].sha1 && !S_ISDIR(entry[2].mode)) {
resolve(base, entry+1, entry+2);
return;
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
}
}
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
if (same_entry(entry+0, entry+2)) {
if (entry[1].sha1 && !S_ISDIR(entry[1].mode)) {
resolve(base, NULL, entry+1);
return;
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
}
}
unresolved(base, entry);
}
static void merge_trees(struct tree_desc t[3], const char *base)
{
traverse_trees(3, t, base, threeway_callback);
Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 03:05:30 +01:00
}
static void *get_tree_descriptor(struct tree_desc *desc, const char *rev)
{
unsigned char sha1[20];
void *buf;
if (get_sha1(rev, sha1) < 0)
die("unknown rev %s", rev);
buf = fill_tree_descriptor(desc, sha1);
if (!buf)
die("%s is not a tree", rev);
return buf;
}
int main(int argc, char **argv)
{
struct tree_desc t[3];
void *buf1, *buf2, *buf3;
if (argc < 4)
usage(merge_tree_usage);
buf1 = get_tree_descriptor(t+0, argv[1]);
buf2 = get_tree_descriptor(t+1, argv[2]);
buf3 = get_tree_descriptor(t+2, argv[3]);
merge_trees(t, "");
free(buf1);
free(buf2);
free(buf3);
return 0;
}