git-commit-vandalism/builtin/merge-tree.c

612 lines
15 KiB
C
Raw Normal View History

#define USE_THE_INDEX_COMPATIBILITY_MACROS
Fix sparse warnings Fix warnings from 'make check'. - These files don't include 'builtin.h' causing sparse to complain that cmd_* isn't declared: builtin/clone.c:364, builtin/fetch-pack.c:797, builtin/fmt-merge-msg.c:34, builtin/hash-object.c:78, builtin/merge-index.c:69, builtin/merge-recursive.c:22 builtin/merge-tree.c:341, builtin/mktag.c:156, builtin/notes.c:426 builtin/notes.c:822, builtin/pack-redundant.c:596, builtin/pack-refs.c:10, builtin/patch-id.c:60, builtin/patch-id.c:149, builtin/remote.c:1512, builtin/remote-ext.c:240, builtin/remote-fd.c:53, builtin/reset.c:236, builtin/send-pack.c:384, builtin/unpack-file.c:25, builtin/var.c:75 - These files have symbols which should be marked static since they're only file scope: submodule.c:12, diff.c:631, replace_object.c:92, submodule.c:13, submodule.c:14, trace.c:78, transport.c:195, transport-helper.c:79, unpack-trees.c:19, url.c:3, url.c:18, url.c:104, url.c:117, url.c:123, url.c:129, url.c:136, thread-utils.c:21, thread-utils.c:48 - These files redeclare symbols to be different types: builtin/index-pack.c:210, parse-options.c:564, parse-options.c:571, usage.c:49, usage.c:58, usage.c:63, usage.c:72 - These files use a literal integer 0 when they really should use a NULL pointer: daemon.c:663, fast-import.c:2942, imap-send.c:1072, notes-merge.c:362 While we're in the area, clean up some unused #includes in builtin files (mostly exec_cmd.h). Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-22 08:51:05 +01:00
#include "builtin.h"
#include "tree-walk.h"
#include "xdiff-interface.h"
merge-tree: implement real merges This adds the ability to perform real merges rather than just trivial merges (meaning handling three way content merges, recursive ancestor consolidation, renames, proper directory/file conflict handling, and so forth). However, unlike `git merge`, the working tree and index are left alone and no branch is updated. The only output is: - the toplevel resulting tree printed on stdout - exit status of 0 (clean), 1 (conflicts present), anything else (merge could not be performed; unknown if clean or conflicted) This output is meant to be used by some higher level script, perhaps in a sequence of steps like this: NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2) test $? -eq 0 || die "There were conflicts..." NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2) git update-ref $BRANCH1 $NEWCOMMIT Note that higher level scripts may also want to access the conflict/warning messages normally output during a merge, or have quick access to a list of files with conflicts. That is not available in this preliminary implementation, but subsequent commits will add that ability (meaning that NEWTREE would be a lot more than a tree in the case of conflicts). This also marks the traditional trivial merge of merge-tree as deprecated. The trivial merge not only had limited applicability, the output format was also difficult to work with (and its format undocumented), and will generally be less performant than real merges. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:47 +02:00
#include "help.h"
#include "commit.h"
merge-tree: implement real merges This adds the ability to perform real merges rather than just trivial merges (meaning handling three way content merges, recursive ancestor consolidation, renames, proper directory/file conflict handling, and so forth). However, unlike `git merge`, the working tree and index are left alone and no branch is updated. The only output is: - the toplevel resulting tree printed on stdout - exit status of 0 (clean), 1 (conflicts present), anything else (merge could not be performed; unknown if clean or conflicted) This output is meant to be used by some higher level script, perhaps in a sequence of steps like this: NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2) test $? -eq 0 || die "There were conflicts..." NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2) git update-ref $BRANCH1 $NEWCOMMIT Note that higher level scripts may also want to access the conflict/warning messages normally output during a merge, or have quick access to a list of files with conflicts. That is not available in this preliminary implementation, but subsequent commits will add that ability (meaning that NEWTREE would be a lot more than a tree in the case of conflicts). This also marks the traditional trivial merge of merge-tree as deprecated. The trivial merge not only had limited applicability, the output format was also difficult to work with (and its format undocumented), and will generally be less performant than real merges. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:47 +02:00
#include "commit-reach.h"
#include "merge-ort.h"
#include "object-store.h"
#include "parse-options.h"
#include "repository.h"
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
#include "blob.h"
#include "exec-cmd.h"
#include "merge-blobs.h"
#include "quote.h"
static int line_termination = '\n';
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
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
struct merge_list {
struct merge_list *next;
struct merge_list *link; /* other stages for this object */
unsigned int stage : 2;
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
unsigned int mode;
const char *path;
struct blob *blob;
};
static struct merge_list *merge_result, **merge_result_end = &merge_result;
static void add_merge_entry(struct merge_list *entry)
{
*merge_result_end = entry;
merge_result_end = &entry->next;
}
static void trivial_merge_trees(struct tree_desc t[3], const char *base);
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
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
static const char *explanation(struct merge_list *entry)
{
switch (entry->stage) {
case 0:
return "merged";
case 3:
return "added in remote";
case 2:
if (entry->link)
return "added in both";
return "added in local";
}
/* Existed in base */
entry = entry->link;
if (!entry)
return "removed in both";
if (entry->link)
return "changed in both";
if (entry->stage == 3)
return "removed in local";
return "removed in remote";
}
static void *result(struct merge_list *entry, unsigned long *size)
{
enum object_type type;
struct blob *base, *our, *their;
const char *path = entry->path;
if (!entry->stage)
return read_object_file(&entry->blob->object.oid, &type, size);
base = NULL;
if (entry->stage == 1) {
base = entry->blob;
entry = entry->link;
}
our = NULL;
if (entry && entry->stage == 2) {
our = entry->blob;
entry = entry->link;
}
their = NULL;
if (entry)
their = entry->blob;
return merge_blobs(the_repository->index, path,
base, our, their, size);
}
static void *origin(struct merge_list *entry, unsigned long *size)
{
enum object_type type;
while (entry) {
if (entry->stage == 2)
return read_object_file(&entry->blob->object.oid,
&type, size);
entry = entry->link;
}
return NULL;
}
static int show_outf(void *priv_, mmbuffer_t *mb, int nbuf)
{
int i;
for (i = 0; i < nbuf; i++)
printf("%.*s", (int) mb[i].size, mb[i].ptr);
return 0;
}
static void show_diff(struct merge_list *entry)
{
unsigned long size;
mmfile_t src, dst;
xpparam_t xpp;
xdemitconf_t xecfg;
xdemitcb_t ecb = { .out_line = show_outf };
memset(&xpp, 0, sizeof(xpp));
xpp.flags = 0;
memset(&xecfg, 0, sizeof(xecfg));
xecfg.ctxlen = 3;
src.ptr = origin(entry, &size);
if (!src.ptr)
size = 0;
src.size = size;
dst.ptr = result(entry, &size);
if (!dst.ptr)
size = 0;
dst.size = size;
react to errors in xdi_diff When we call into xdiff to perform a diff, we generally lose the return code completely. Typically by ignoring the return of our xdi_diff wrapper, but sometimes we even propagate that return value up and then ignore it later. This can lead to us silently producing incorrect diffs (e.g., "git log" might produce no output at all, not even a diff header, for a content-level diff). In practice this does not happen very often, because the typical reason for xdiff to report failure is that it malloc() failed (it uses straight malloc, and not our xmalloc wrapper). But it could also happen when xdiff triggers one our callbacks, which returns an error (e.g., outf() in builtin/rerere.c tries to report a write failure in this way). And the next patch also plans to add more failure modes. Let's notice an error return from xdiff and react appropriately. In most of the diff.c code, we can simply die(), which matches the surrounding code (e.g., that is what we do if we fail to load a file for diffing in the first place). This is not that elegant, but we are probably better off dying to let the user know there was a problem, rather than simply generating bogus output. We could also just die() directly in xdi_diff, but the callers typically have a bit more context, and can provide a better message (and if we do later decide to pass errors up, we're one step closer to doing so). There is one interesting case, which is in diff_grep(). Here if we cannot generate the diff, there is nothing to match, and we silently return "no hits". This is actually what the existing code does already, but we make it a little more explicit. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25 01:12:23 +02:00
if (xdi_diff(&src, &dst, &xpp, &xecfg, &ecb))
die("unable to generate diff");
free(src.ptr);
free(dst.ptr);
}
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
static void show_result_list(struct merge_list *entry)
{
printf("%s\n", explanation(entry));
do {
struct merge_list *link = entry->link;
static const char *desc[4] = { "result", "base", "our", "their" };
printf(" %-6s %o %s %s\n", desc[entry->stage], entry->mode, oid_to_hex(&entry->blob->object.oid), entry->path);
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
entry = link;
} while (entry);
}
static void show_result(void)
{
struct merge_list *walk;
walk = merge_result;
while (walk) {
show_result_list(walk);
show_diff(walk);
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
walk = walk->next;
}
}
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
/* 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 !is_null_oid(&a->oid) &&
!is_null_oid(&b->oid) &&
oideq(&a->oid, &b->oid) &&
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
a->mode == b->mode;
}
static int both_empty(struct name_entry *a, struct name_entry *b)
{
return is_null_oid(&a->oid) && is_null_oid(&b->oid);
}
static struct merge_list *create_entry(unsigned stage, unsigned mode, const struct object_id *oid, const char *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
{
struct merge_list *res = xcalloc(1, sizeof(*res));
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
res->stage = stage;
res->path = path;
res->mode = mode;
res->blob = lookup_blob(the_repository, oid);
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
return res;
}
static char *traverse_path(const struct traverse_info *info, const struct name_entry *n)
{
struct strbuf buf = STRBUF_INIT;
strbuf_make_traverse_path(&buf, info, n->path, n->pathlen);
return strbuf_detach(&buf, NULL);
}
static void resolve(const struct traverse_info *info, struct name_entry *ours, struct name_entry *result)
{
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
struct merge_list *orig, *final;
const char *path;
/* If it's already ours, don't bother showing it */
if (!ours)
return;
path = traverse_path(info, result);
orig = create_entry(2, ours->mode, &ours->oid, path);
final = create_entry(0, result->mode, &result->oid, path);
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
final->link = orig;
add_merge_entry(final);
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 unresolved_directory(const struct traverse_info *info,
struct name_entry n[3])
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 repository *r = the_repository;
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
char *newbase;
struct name_entry *p;
struct tree_desc t[3];
void *buf0, *buf1, *buf2;
for (p = n; p < n + 3; p++) {
if (p->mode && S_ISDIR(p->mode))
break;
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 (n + 3 <= p)
return; /* there is no tree here */
newbase = traverse_path(info, p);
#define ENTRY_OID(e) (((e)->mode && S_ISDIR((e)->mode)) ? &(e)->oid : NULL)
buf0 = fill_tree_descriptor(r, t + 0, ENTRY_OID(n + 0));
buf1 = fill_tree_descriptor(r, t + 1, ENTRY_OID(n + 1));
buf2 = fill_tree_descriptor(r, t + 2, ENTRY_OID(n + 2));
#undef ENTRY_OID
trivial_merge_trees(t, newbase);
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
free(buf0);
free(buf1);
free(buf2);
free(newbase);
}
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
static struct merge_list *link_entry(unsigned stage, const struct traverse_info *info, struct name_entry *n, struct merge_list *entry)
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
{
const char *path;
struct merge_list *link;
if (!n->mode)
return entry;
if (entry)
path = entry->path;
else
path = traverse_path(info, n);
link = create_entry(stage, n->mode, &n->oid, path);
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
link->link = entry;
return link;
}
static void unresolved(const struct traverse_info *info, struct name_entry n[3])
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
{
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
struct merge_list *entry = NULL;
int i;
unsigned dirmask = 0, mask = 0;
for (i = 0; i < 3; i++) {
mask |= (1 << i);
/*
* Treat missing entries as directories so that we return
* after unresolved_directory has handled this.
*/
if (!n[i].mode || S_ISDIR(n[i].mode))
dirmask |= (1 << i);
}
unresolved_directory(info, n);
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
if (dirmask == mask)
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
return;
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
if (n[2].mode && !S_ISDIR(n[2].mode))
entry = link_entry(3, info, n + 2, entry);
if (n[1].mode && !S_ISDIR(n[1].mode))
entry = link_entry(2, info, n + 1, entry);
if (n[0].mode && !S_ISDIR(n[0].mode))
entry = link_entry(1, info, n + 0, entry);
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
add_merge_entry(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 int threeway_callback(int n, unsigned long mask, unsigned long dirmask, struct name_entry *entry, struct traverse_info *info)
{
/* Same in both? */
if (same_entry(entry+1, entry+2) || both_empty(entry+1, entry+2)) {
/* Modified, added or removed identically */
resolve(info, NULL, entry+1);
return mask;
}
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 (!is_null_oid(&entry[2].oid) && !S_ISDIR(entry[2].mode)) {
/* We did not touch, they modified -- take theirs */
resolve(info, entry+1, entry+2);
return mask;
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 we did not touch a directory but they made it
* into a file, we fall through and unresolved()
* recurses down. Likewise for the opposite case.
*/
}
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) || both_empty(entry+0, entry+2)) {
/* We added, modified or removed, they did not touch -- take ours */
resolve(info, NULL, entry+1);
return mask;
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(info, entry);
return mask;
}
static void trivial_merge_trees(struct tree_desc t[3], const char *base)
{
struct traverse_info info;
setup_traverse_info(&info, base);
info.fn = threeway_callback;
traverse_trees(&the_index, 3, t, &info);
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 repository *r,
struct tree_desc *desc,
const char *rev)
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 object_id oid;
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
void *buf;
if (repo_get_oid(r, rev, &oid))
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
die("unknown rev %s", rev);
buf = fill_tree_descriptor(r, desc, &oid);
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 (!buf)
die("%s is not a tree", rev);
return buf;
}
static int trivial_merge(const char *base,
const char *branch1,
const char *branch2)
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 repository *r = the_repository;
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 tree_desc t[3];
void *buf1, *buf2, *buf3;
buf1 = get_tree_descriptor(r, t+0, base);
buf2 = get_tree_descriptor(r, t+1, branch1);
buf3 = get_tree_descriptor(r, t+2, branch2);
trivial_merge_trees(t, "");
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
free(buf1);
free(buf2);
free(buf3);
Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit 5ab2c0a47574c92f92ea3709b23ca35d96319edd in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree 64e86c57 c5c23745 928e47e3 where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 20:18:27 +02:00
show_result();
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
return 0;
}
enum mode {
MODE_UNKNOWN,
MODE_TRIVIAL,
MODE_REAL,
};
struct merge_tree_options {
int mode;
int allow_unrelated_histories;
int show_messages;
int name_only;
int use_stdin;
};
static int real_merge(struct merge_tree_options *o,
const char *merge_base,
const char *branch1, const char *branch2,
const char *prefix)
{
merge-tree: implement real merges This adds the ability to perform real merges rather than just trivial merges (meaning handling three way content merges, recursive ancestor consolidation, renames, proper directory/file conflict handling, and so forth). However, unlike `git merge`, the working tree and index are left alone and no branch is updated. The only output is: - the toplevel resulting tree printed on stdout - exit status of 0 (clean), 1 (conflicts present), anything else (merge could not be performed; unknown if clean or conflicted) This output is meant to be used by some higher level script, perhaps in a sequence of steps like this: NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2) test $? -eq 0 || die "There were conflicts..." NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2) git update-ref $BRANCH1 $NEWCOMMIT Note that higher level scripts may also want to access the conflict/warning messages normally output during a merge, or have quick access to a list of files with conflicts. That is not available in this preliminary implementation, but subsequent commits will add that ability (meaning that NEWTREE would be a lot more than a tree in the case of conflicts). This also marks the traditional trivial merge of merge-tree as deprecated. The trivial merge not only had limited applicability, the output format was also difficult to work with (and its format undocumented), and will generally be less performant than real merges. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:47 +02:00
struct commit *parent1, *parent2;
struct commit_list *merge_bases = NULL;
struct merge_options opt;
struct merge_result result = { 0 };
int show_messages = o->show_messages;
merge-tree: implement real merges This adds the ability to perform real merges rather than just trivial merges (meaning handling three way content merges, recursive ancestor consolidation, renames, proper directory/file conflict handling, and so forth). However, unlike `git merge`, the working tree and index are left alone and no branch is updated. The only output is: - the toplevel resulting tree printed on stdout - exit status of 0 (clean), 1 (conflicts present), anything else (merge could not be performed; unknown if clean or conflicted) This output is meant to be used by some higher level script, perhaps in a sequence of steps like this: NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2) test $? -eq 0 || die "There were conflicts..." NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2) git update-ref $BRANCH1 $NEWCOMMIT Note that higher level scripts may also want to access the conflict/warning messages normally output during a merge, or have quick access to a list of files with conflicts. That is not available in this preliminary implementation, but subsequent commits will add that ability (meaning that NEWTREE would be a lot more than a tree in the case of conflicts). This also marks the traditional trivial merge of merge-tree as deprecated. The trivial merge not only had limited applicability, the output format was also difficult to work with (and its format undocumented), and will generally be less performant than real merges. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:47 +02:00
parent1 = get_merge_parent(branch1);
if (!parent1)
help_unknown_ref(branch1, "merge-tree",
_("not something we can merge"));
parent2 = get_merge_parent(branch2);
if (!parent2)
help_unknown_ref(branch2, "merge-tree",
_("not something we can merge"));
init_merge_options(&opt, the_repository);
opt.show_rename_progress = 0;
opt.branch1 = branch1;
opt.branch2 = branch2;
if (merge_base) {
struct commit *base_commit;
struct tree *base_tree, *parent1_tree, *parent2_tree;
base_commit = lookup_commit_reference_by_name(merge_base);
if (!base_commit)
die(_("could not lookup commit %s"), merge_base);
opt.ancestor = merge_base;
base_tree = get_commit_tree(base_commit);
parent1_tree = get_commit_tree(parent1);
parent2_tree = get_commit_tree(parent2);
merge_incore_nonrecursive(&opt, base_tree, parent1_tree, parent2_tree, &result);
} else {
/*
* Get the merge bases, in reverse order; see comment above
* merge_incore_recursive in merge-ort.h
*/
merge_bases = get_merge_bases(parent1, parent2);
if (!merge_bases && !o->allow_unrelated_histories)
die(_("refusing to merge unrelated histories"));
merge_bases = reverse_commit_list(merge_bases);
merge_incore_recursive(&opt, merge_bases, parent1, parent2, &result);
}
merge-tree: implement real merges This adds the ability to perform real merges rather than just trivial merges (meaning handling three way content merges, recursive ancestor consolidation, renames, proper directory/file conflict handling, and so forth). However, unlike `git merge`, the working tree and index are left alone and no branch is updated. The only output is: - the toplevel resulting tree printed on stdout - exit status of 0 (clean), 1 (conflicts present), anything else (merge could not be performed; unknown if clean or conflicted) This output is meant to be used by some higher level script, perhaps in a sequence of steps like this: NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2) test $? -eq 0 || die "There were conflicts..." NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2) git update-ref $BRANCH1 $NEWCOMMIT Note that higher level scripts may also want to access the conflict/warning messages normally output during a merge, or have quick access to a list of files with conflicts. That is not available in this preliminary implementation, but subsequent commits will add that ability (meaning that NEWTREE would be a lot more than a tree in the case of conflicts). This also marks the traditional trivial merge of merge-tree as deprecated. The trivial merge not only had limited applicability, the output format was also difficult to work with (and its format undocumented), and will generally be less performant than real merges. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:47 +02:00
if (result.clean < 0)
die(_("failure to merge"));
if (show_messages == -1)
show_messages = !result.clean;
if (o->use_stdin)
printf("%d%c", result.clean, line_termination);
printf("%s%c", oid_to_hex(&result.tree->object.oid), line_termination);
if (!result.clean) {
struct string_list conflicted_files = STRING_LIST_INIT_NODUP;
const char *last = NULL;
int i;
merge_get_conflicted_files(&result, &conflicted_files);
for (i = 0; i < conflicted_files.nr; i++) {
const char *name = conflicted_files.items[i].string;
struct stage_info *c = conflicted_files.items[i].util;
if (!o->name_only)
printf("%06o %s %d\t",
c->mode, oid_to_hex(&c->oid), c->stage);
else if (last && !strcmp(last, name))
continue;
write_name_quoted_relative(
name, prefix, stdout, line_termination);
last = name;
}
string_list_clear(&conflicted_files, 1);
}
if (show_messages) {
putchar(line_termination);
merge_display_update_messages(&opt, line_termination == '\0',
&result);
}
if (o->use_stdin)
putchar(line_termination);
merge-tree: implement real merges This adds the ability to perform real merges rather than just trivial merges (meaning handling three way content merges, recursive ancestor consolidation, renames, proper directory/file conflict handling, and so forth). However, unlike `git merge`, the working tree and index are left alone and no branch is updated. The only output is: - the toplevel resulting tree printed on stdout - exit status of 0 (clean), 1 (conflicts present), anything else (merge could not be performed; unknown if clean or conflicted) This output is meant to be used by some higher level script, perhaps in a sequence of steps like this: NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2) test $? -eq 0 || die "There were conflicts..." NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2) git update-ref $BRANCH1 $NEWCOMMIT Note that higher level scripts may also want to access the conflict/warning messages normally output during a merge, or have quick access to a list of files with conflicts. That is not available in this preliminary implementation, but subsequent commits will add that ability (meaning that NEWTREE would be a lot more than a tree in the case of conflicts). This also marks the traditional trivial merge of merge-tree as deprecated. The trivial merge not only had limited applicability, the output format was also difficult to work with (and its format undocumented), and will generally be less performant than real merges. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:47 +02:00
merge_finalize(&opt, &result);
return !result.clean; /* result.clean < 0 handled above */
}
int cmd_merge_tree(int argc, const char **argv, const char *prefix)
{
struct merge_tree_options o = { .show_messages = -1 };
int expected_remaining_argc;
int original_argc;
const char *merge_base = NULL;
const char * const merge_tree_usage[] = {
N_("git merge-tree [--write-tree] [<options>] <branch1> <branch2>"),
N_("git merge-tree [--trivial-merge] <base-tree> <branch1> <branch2>"),
NULL
};
struct option mt_options[] = {
OPT_CMDMODE(0, "write-tree", &o.mode,
N_("do a real merge instead of a trivial merge"),
MODE_REAL),
OPT_CMDMODE(0, "trivial-merge", &o.mode,
N_("do a trivial merge only"), MODE_TRIVIAL),
OPT_BOOL(0, "messages", &o.show_messages,
N_("also show informational/conflict messages")),
OPT_SET_INT('z', NULL, &line_termination,
N_("separate paths with the NUL character"), '\0'),
OPT_BOOL_F(0, "name-only",
&o.name_only,
N_("list filenames without modes/oids/stages"),
PARSE_OPT_NONEG),
OPT_BOOL_F(0, "allow-unrelated-histories",
&o.allow_unrelated_histories,
N_("allow merging unrelated histories"),
PARSE_OPT_NONEG),
OPT_BOOL_F(0, "stdin",
&o.use_stdin,
N_("perform multiple merges, one per line of input"),
PARSE_OPT_NONEG),
OPT_STRING(0, "merge-base",
&merge_base,
N_("commit"),
N_("specify a merge-base for the merge")),
OPT_END()
};
/* Parse arguments */
original_argc = argc - 1; /* ignoring argv[0] */
argc = parse_options(argc, argv, prefix, mt_options,
merge_tree_usage, PARSE_OPT_STOP_AT_NON_OPTION);
/* Handle --stdin */
if (o.use_stdin) {
struct strbuf buf = STRBUF_INIT;
if (o.mode == MODE_TRIVIAL)
die(_("--trivial-merge is incompatible with all other options"));
if (merge_base)
die(_("--merge-base is incompatible with --stdin"));
line_termination = '\0';
while (strbuf_getline_lf(&buf, stdin) != EOF) {
struct strbuf **split;
int result;
split = strbuf_split(&buf, ' ');
if (!split[0] || !split[1] || split[2])
die(_("malformed input line: '%s'."), buf.buf);
strbuf_rtrim(split[0]);
result = real_merge(&o, merge_base, split[0]->buf, split[1]->buf, prefix);
if (result < 0)
die(_("merging cannot continue; got unclean result of %d"), result);
strbuf_list_free(split);
}
strbuf_release(&buf);
return 0;
}
/* Figure out which mode to use */
switch (o.mode) {
default:
BUG("unexpected command mode %d", o.mode);
case MODE_UNKNOWN:
switch (argc) {
default:
usage_with_options(merge_tree_usage, mt_options);
case 2:
o.mode = MODE_REAL;
break;
case 3:
o.mode = MODE_TRIVIAL;
break;
}
expected_remaining_argc = argc;
break;
case MODE_REAL:
expected_remaining_argc = 2;
break;
case MODE_TRIVIAL:
expected_remaining_argc = 3;
/* Removal of `--trivial-merge` is expected */
original_argc--;
break;
}
if (o.mode == MODE_TRIVIAL && argc < original_argc)
die(_("--trivial-merge is incompatible with all other options"));
if (argc != expected_remaining_argc)
usage_with_options(merge_tree_usage, mt_options);
/* Do the relevant type of merge */
if (o.mode == MODE_REAL)
return real_merge(&o, merge_base, argv[0], argv[1], prefix);
else
return trivial_merge(argv[0], argv[1], argv[2]);
}