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 15:51:05 +08:00
|
|
|
#include "builtin.h"
|
2006-03-30 14:55:43 +08:00
|
|
|
#include "tree-walk.h"
|
2006-06-29 13:06:36 +08:00
|
|
|
#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 08:20:47 +08:00
|
|
|
#include "help.h"
|
2023-03-21 14:25:54 +08:00
|
|
|
#include "gettext.h"
|
2023-02-24 08:09:27 +08:00
|
|
|
#include "hex.h"
|
2022-11-12 07:45:13 +08:00
|
|
|
#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 08:20:47 +08:00
|
|
|
#include "commit-reach.h"
|
|
|
|
|
#include "merge-ort.h"
|
2023-04-11 15:41:49 +08:00
|
|
|
#include "object-name.h"
|
2023-05-16 14:34:06 +08:00
|
|
|
#include "object-store-ll.h"
|
2022-06-18 08:20:46 +08:00
|
|
|
#include "parse-options.h"
|
2018-06-29 09:21:55 +08:00
|
|
|
#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-29 02:18:27 +08:00
|
|
|
#include "blob.h"
|
2012-12-07 07:08:01 +08:00
|
|
|
#include "merge-blobs.h"
|
2022-06-18 08:20:52 +08:00
|
|
|
#include "quote.h"
|
2023-04-23 04:17:26 +08:00
|
|
|
#include "tree.h"
|
2023-05-11 03:07:34 +08:00
|
|
|
#include "config.h"
|
2023-09-24 10:23:42 +08:00
|
|
|
#include "strvec.h"
|
2022-06-18 08:20:52 +08:00
|
|
|
|
|
|
|
|
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 10:05:30 +08: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-29 02:18:27 +08:00
|
|
|
struct merge_list {
|
|
|
|
|
struct merge_list *next;
|
|
|
|
|
struct merge_list *link; /* other stages for this object */
|
|
|
|
|
|
2012-12-07 07:41:04 +08:00
|
|
|
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-29 02:18:27 +08: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;
|
|
|
|
|
}
|
|
|
|
|
|
2022-06-18 08:20:44 +08:00
|
|
|
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 10:05:30 +08: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-29 02:18:27 +08: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";
|
|
|
|
|
}
|
|
|
|
|
|
2006-06-29 13:06:36 +08:00
|
|
|
static void *result(struct merge_list *entry, unsigned long *size)
|
|
|
|
|
{
|
2007-02-27 03:55:59 +08:00
|
|
|
enum object_type type;
|
2006-06-29 13:06:36 +08:00
|
|
|
struct blob *base, *our, *their;
|
2010-07-15 01:04:07 +08:00
|
|
|
const char *path = entry->path;
|
2006-06-29 13:06:36 +08:00
|
|
|
|
|
|
|
|
if (!entry->stage)
|
2023-03-28 21:58:50 +08:00
|
|
|
return repo_read_object_file(the_repository,
|
|
|
|
|
&entry->blob->object.oid, &type,
|
|
|
|
|
size);
|
2006-06-29 13:06:36 +08:00
|
|
|
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;
|
2019-01-24 16:29:12 +08:00
|
|
|
return merge_blobs(the_repository->index, path,
|
|
|
|
|
base, our, their, size);
|
2006-06-29 13:06:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void *origin(struct merge_list *entry, unsigned long *size)
|
|
|
|
|
{
|
2007-02-27 03:55:59 +08:00
|
|
|
enum object_type type;
|
2006-06-29 13:06:36 +08:00
|
|
|
while (entry) {
|
|
|
|
|
if (entry->stage == 2)
|
2023-03-28 21:58:50 +08:00
|
|
|
return repo_read_object_file(the_repository,
|
|
|
|
|
&entry->blob->object.oid,
|
|
|
|
|
&type, size);
|
2006-06-29 13:06:36 +08:00
|
|
|
entry = entry->link;
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2022-12-13 19:13:48 +08:00
|
|
|
static int show_outf(void *priv UNUSED, mmbuffer_t *mb, int nbuf)
|
2006-06-29 13:06:36 +08:00
|
|
|
{
|
|
|
|
|
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;
|
2021-04-13 01:15:28 +08:00
|
|
|
xdemitcb_t ecb = { .out_line = show_outf };
|
2006-06-29 13:06:36 +08:00
|
|
|
|
2020-10-20 14:48:08 +08:00
|
|
|
memset(&xpp, 0, sizeof(xpp));
|
2010-05-02 21:04:41 +08:00
|
|
|
xpp.flags = 0;
|
2007-07-05 02:05:46 +08:00
|
|
|
memset(&xecfg, 0, sizeof(xecfg));
|
2006-06-29 13:06:36 +08:00
|
|
|
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 07:12:23 +08:00
|
|
|
if (xdi_diff(&src, &dst, &xpp, &xecfg, &ecb))
|
|
|
|
|
die("unable to generate diff");
|
2006-06-29 13:06:36 +08:00
|
|
|
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-29 02:18:27 +08: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" };
|
2015-11-10 10:22:28 +08:00
|
|
|
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-29 02:18:27 +08:00
|
|
|
entry = link;
|
|
|
|
|
} while (entry);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void show_result(void)
|
|
|
|
|
{
|
|
|
|
|
struct merge_list *walk;
|
|
|
|
|
|
|
|
|
|
walk = merge_result;
|
|
|
|
|
while (walk) {
|
|
|
|
|
show_result_list(walk);
|
2006-06-29 13:06:36 +08:00
|
|
|
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-29 02:18:27 +08: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 10:05:30 +08: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)
|
|
|
|
|
{
|
2019-01-15 08:39:44 +08:00
|
|
|
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 10:05:30 +08:00
|
|
|
a->mode == b->mode;
|
|
|
|
|
}
|
|
|
|
|
|
2013-04-08 05:07:51 +08:00
|
|
|
static int both_empty(struct name_entry *a, struct name_entry *b)
|
|
|
|
|
{
|
2019-01-15 08:39:44 +08:00
|
|
|
return is_null_oid(&a->oid) && is_null_oid(&b->oid);
|
2013-04-08 05:07:51 +08:00
|
|
|
}
|
|
|
|
|
|
2017-05-07 06:10:13 +08:00
|
|
|
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 10:05:30 +08:00
|
|
|
{
|
2008-10-07 07:39:10 +08: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-29 02:18:27 +08:00
|
|
|
|
|
|
|
|
res->stage = stage;
|
|
|
|
|
res->path = path;
|
|
|
|
|
res->mode = mode;
|
2018-06-29 09:21:55 +08:00
|
|
|
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-29 02:18:27 +08:00
|
|
|
return res;
|
Handling large files with GIT
On Tue, 14 Feb 2006, Linus Torvalds wrote:
>
> Here, btw, is the trivial diff to turn my previous "tree-resolve" into a
> "resolve tree relative to the current branch".
Gaah. It was trivial, and it happened to work fine for my test-case, but
when I started looking at not doing that extremely aggressive subdirectory
merging, that showed a few other issues...
So in case people want to try, here's a third patch. Oh, and it's against
my _original_ path, not incremental to the middle one (ie both patches two
and three are against patch #1, it's not a nice series).
Now I'm really done, and won't be sending out any more patches today.
Sorry for the noise.
Linus
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 10:33:02 +08:00
|
|
|
}
|
|
|
|
|
|
2008-03-06 10:59:29 +08:00
|
|
|
static char *traverse_path(const struct traverse_info *info, const struct name_entry *n)
|
|
|
|
|
{
|
2019-07-31 12:38:23 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
strbuf_make_traverse_path(&buf, info, n->path, n->pathlen);
|
|
|
|
|
return strbuf_detach(&buf, NULL);
|
2008-03-06 10:59:29 +08:00
|
|
|
}
|
|
|
|
|
|
2012-12-07 08:15:45 +08:00
|
|
|
static void resolve(const struct traverse_info *info, struct name_entry *ours, struct name_entry *result)
|
Handling large files with GIT
On Tue, 14 Feb 2006, Linus Torvalds wrote:
>
> Here, btw, is the trivial diff to turn my previous "tree-resolve" into a
> "resolve tree relative to the current branch".
Gaah. It was trivial, and it happened to work fine for my test-case, but
when I started looking at not doing that extremely aggressive subdirectory
merging, that showed a few other issues...
So in case people want to try, here's a third patch. Oh, and it's against
my _original_ path, not incremental to the middle one (ie both patches two
and three are against patch #1, it's not a nice series).
Now I'm really done, and won't be sending out any more patches today.
Sorry for the noise.
Linus
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 10:33:02 +08: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-29 02:18:27 +08:00
|
|
|
struct merge_list *orig, *final;
|
|
|
|
|
const char *path;
|
|
|
|
|
|
2012-12-07 08:15:45 +08:00
|
|
|
/* If it's already ours, don't bother showing it */
|
|
|
|
|
if (!ours)
|
Handling large files with GIT
On Tue, 14 Feb 2006, Linus Torvalds wrote:
>
> Here, btw, is the trivial diff to turn my previous "tree-resolve" into a
> "resolve tree relative to the current branch".
Gaah. It was trivial, and it happened to work fine for my test-case, but
when I started looking at not doing that extremely aggressive subdirectory
merging, that showed a few other issues...
So in case people want to try, here's a third patch. Oh, and it's against
my _original_ path, not incremental to the middle one (ie both patches two
and three are against patch #1, it's not a nice series).
Now I'm really done, and won't be sending out any more patches today.
Sorry for the noise.
Linus
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 10:33:02 +08:00
|
|
|
return;
|
|
|
|
|
|
2008-03-06 10:59:29 +08:00
|
|
|
path = traverse_path(info, result);
|
2019-01-15 08:39:44 +08:00
|
|
|
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-29 02:18:27 +08: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 10:05:30 +08:00
|
|
|
}
|
|
|
|
|
|
2014-08-31 05:40:34 +08: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 10:05:30 +08:00
|
|
|
{
|
2019-06-27 17:28:48 +08: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 10:05:30 +08:00
|
|
|
char *newbase;
|
|
|
|
|
struct name_entry *p;
|
|
|
|
|
struct tree_desc t[3];
|
|
|
|
|
void *buf0, *buf1, *buf2;
|
|
|
|
|
|
2012-12-14 07:51:29 +08:00
|
|
|
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 10:05:30 +08:00
|
|
|
}
|
2012-12-14 07:51:29 +08:00
|
|
|
if (n + 3 <= p)
|
|
|
|
|
return; /* there is no tree here */
|
2012-12-07 08:15:45 +08:00
|
|
|
|
2008-03-06 10:59:29 +08:00
|
|
|
newbase = traverse_path(info, p);
|
2012-12-14 07:51:29 +08:00
|
|
|
|
2019-01-15 08:39:44 +08:00
|
|
|
#define ENTRY_OID(e) (((e)->mode && S_ISDIR((e)->mode)) ? &(e)->oid : NULL)
|
2019-06-27 17:28:48 +08:00
|
|
|
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));
|
2017-08-12 16:32:59 +08:00
|
|
|
#undef ENTRY_OID
|
2012-12-14 07:51:29 +08:00
|
|
|
|
2022-06-18 08:20:44 +08:00
|
|
|
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 10:05:30 +08: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-29 02:18:27 +08:00
|
|
|
|
2008-03-06 10:59:29 +08: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-29 02:18:27 +08:00
|
|
|
{
|
|
|
|
|
const char *path;
|
|
|
|
|
struct merge_list *link;
|
|
|
|
|
|
|
|
|
|
if (!n->mode)
|
|
|
|
|
return entry;
|
|
|
|
|
if (entry)
|
|
|
|
|
path = entry->path;
|
|
|
|
|
else
|
2008-03-06 10:59:29 +08:00
|
|
|
path = traverse_path(info, n);
|
2019-01-15 08:39:44 +08:00
|
|
|
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-29 02:18:27 +08:00
|
|
|
link->link = entry;
|
|
|
|
|
return link;
|
|
|
|
|
}
|
|
|
|
|
|
2008-03-06 10:59:29 +08:00
|
|
|
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 10:05:30 +08: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-29 02:18:27 +08:00
|
|
|
struct merge_list *entry = NULL;
|
2012-12-14 07:51:29 +08:00
|
|
|
int i;
|
|
|
|
|
unsigned dirmask = 0, mask = 0;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < 3; i++) {
|
2013-03-27 23:58:50 +08:00
|
|
|
mask |= (1 << i);
|
2013-05-06 23:20:54 +08:00
|
|
|
/*
|
|
|
|
|
* Treat missing entries as directories so that we return
|
|
|
|
|
* after unresolved_directory has handled this.
|
|
|
|
|
*/
|
|
|
|
|
if (!n[i].mode || S_ISDIR(n[i].mode))
|
2012-12-14 07:51:29 +08:00
|
|
|
dirmask |= (1 << i);
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-31 05:40:34 +08:00
|
|
|
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-29 02:18:27 +08:00
|
|
|
|
2012-12-14 07:51:29 +08: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 10:05:30 +08: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-29 02:18:27 +08:00
|
|
|
|
2012-12-14 07:51:29 +08: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-29 02:18:27 +08: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 10:05:30 +08:00
|
|
|
}
|
|
|
|
|
|
2006-02-16 11:25:32 +08: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.
|
|
|
|
|
*/
|
2023-07-03 14:44:21 +08:00
|
|
|
static int threeway_callback(int n UNUSED, unsigned long mask,
|
|
|
|
|
unsigned long dirmask UNUSED,
|
|
|
|
|
struct name_entry *entry, struct traverse_info *info)
|
2006-02-16 11:25:32 +08:00
|
|
|
{
|
|
|
|
|
/* Same in both? */
|
2013-04-27 21:40:33 +08:00
|
|
|
if (same_entry(entry+1, entry+2) || both_empty(entry+1, entry+2)) {
|
2013-04-08 05:07:51 +08:00
|
|
|
/* Modified, added or removed identically */
|
|
|
|
|
resolve(info, NULL, entry+1);
|
|
|
|
|
return mask;
|
2006-02-16 11:25:32 +08:00
|
|
|
}
|
Handling large files with GIT
On Tue, 14 Feb 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > If somebody is interested in making the "lots of filename changes" case go
> > fast, I'd be more than happy to walk them through what they'd need to
> > change. I'm just not horribly motivated to do it myself. Hint, hint.
>
> In case anybody is wondering, I share the same feeling. I
> cannot say I'd be "more than happy to" clean up potential
> breakages during the development of such changes, but if the
> change eventually would help certain use cases, I can be
> persuaded to help debugging such a mess ;-).
Actually, I got interested in seeing how hard this is, and wrote a simple
first cut at doing a tree-optimized merger.
Let me shout a bit first:
THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION
RATHER THAN THE FINAL PRODUCT!
With that out of the way, let me descibe what this does (and then describe
the missing parts).
This is basically a three-way merge that works entirely on the "tree"
level, rather than on the index. A lot of the _concepts_ are the same,
though, and if you're familiar with the results of an index merge, some of
the output will make more sense.
You give it three trees: the base tree (tree 0), and the two branches to
be merged (tree 1 and tree 2 respectively). It will then walk these three
trees, and resolve them as it goes along.
The interesting part is:
- it can resolve whole sub-directories in one go, without actually even
looking recursively at them. A whole subdirectory will resolve the same
way as any individual files will (although that may need some
modification, see later).
- if it has a "content conflict", for subdirectories that means "try to
do a recursive tree merge", while for non-subdirectories it's just a
content conflict and we'll output the stage 1/2/3 information.
- a successful merge will output a single stage 0 ("merged") entry,
potentially for a whole subdirectory.
- it outputs all the resolve information on stdout, so something like the
recursive resolver can pretty easily parse it all.
Now, the caveats:
- we probably need to be more careful about subdirectory resolves. The
trivial case (both branches have the exact same subdirectory) is a
trivial resolve, but the other cases ("branch1 matches base, branch2 is
different" probably can't be silently just resolved to the "branch2"
subdirectory state, since it might involve renames into - or out of -
that subdirectory)
- we do not track the current index file at all, so this does not do the
"check that index matches branch1" logic that the three-way merge in
git-read-tree does. The theory is that we'd do a full three-way merge
(ignoring the index and working directory), and then to update the
working tree, we'd do a two-way "git-read-tree branch1->result"
- I didn't actually make it do all the trivial resolve cases that
git-read-tree does. It's a technology demonstration.
Finally (a more serious caveat):
- doing things through stdout may end up being so expensive that we'd
need to do something else. In particular, it's likely that I should
not actually output the "merge results", but instead output a "merge
results as they _differ_ from branch1"
However, I think this patch is already interesting enough that people who
are interested in merging trees might want to look at it. Please keep in
mind that tech _demo_ part, and in particular, keep in mind the final
"serious caveat" part.
In many ways, the really _interesting_ part of a merge is not the result,
but how it _changes_ the branch we're merging into. That's particularly
important as it should hopefully also mean that the output size for any
reasonable case is minimal (and tracks what we actually need to do to the
current state to create the final result).
The code very much is organized so that doing the result as a "diff
against branch1" should be quite easy/possible. I was actually going to do
it, but I decided that it probably makes the output harder to read. I
dunno.
Anyway, let's think about this kind of approach.. Note how the code itself
is actually quite small and short, although it's prbably pretty "dense".
As an interesting test-case, I'd suggest this merge in the kernel:
git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc
which resolves beautifully (there are no actual file-level conflicts), and
you can look at the output of that command to start thinking about what
it does.
The interesting part (perhaps) is that timing that command for me shows
that it takes all of 0.004 seconds.. (the git-merge-base thing takes
considerably more ;)
The point is, we _can_ do the actual merge part really really quickly.
Linus
PS. Final note: when I say that it is "WORKING CODE", that is obviously by
my standards. IOW, I tested it once and it gave reasonable results - so it
must be perfect.
Whether it works for anybody else, or indeed for any other test-case, is
not my problem ;)
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 10:05:30 +08:00
|
|
|
|
2006-02-16 11:25:32 +08:00
|
|
|
if (same_entry(entry+0, entry+1)) {
|
2019-01-15 08:39:44 +08:00
|
|
|
if (!is_null_oid(&entry[2].oid) && !S_ISDIR(entry[2].mode)) {
|
2012-12-07 08:15:45 +08:00
|
|
|
/* We did not touch, they modified -- take theirs */
|
2008-03-06 10:59:29 +08:00
|
|
|
resolve(info, entry+1, entry+2);
|
2008-03-06 11:44:06 +08:00
|
|
|
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 10:05:30 +08:00
|
|
|
}
|
2012-12-07 08:15:45 +08: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.
|
|
|
|
|
*/
|
2006-02-16 11:25:32 +08:00
|
|
|
}
|
Handling large files with GIT
On Tue, 14 Feb 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > If somebody is interested in making the "lots of filename changes" case go
> > fast, I'd be more than happy to walk them through what they'd need to
> > change. I'm just not horribly motivated to do it myself. Hint, hint.
>
> In case anybody is wondering, I share the same feeling. I
> cannot say I'd be "more than happy to" clean up potential
> breakages during the development of such changes, but if the
> change eventually would help certain use cases, I can be
> persuaded to help debugging such a mess ;-).
Actually, I got interested in seeing how hard this is, and wrote a simple
first cut at doing a tree-optimized merger.
Let me shout a bit first:
THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION
RATHER THAN THE FINAL PRODUCT!
With that out of the way, let me descibe what this does (and then describe
the missing parts).
This is basically a three-way merge that works entirely on the "tree"
level, rather than on the index. A lot of the _concepts_ are the same,
though, and if you're familiar with the results of an index merge, some of
the output will make more sense.
You give it three trees: the base tree (tree 0), and the two branches to
be merged (tree 1 and tree 2 respectively). It will then walk these three
trees, and resolve them as it goes along.
The interesting part is:
- it can resolve whole sub-directories in one go, without actually even
looking recursively at them. A whole subdirectory will resolve the same
way as any individual files will (although that may need some
modification, see later).
- if it has a "content conflict", for subdirectories that means "try to
do a recursive tree merge", while for non-subdirectories it's just a
content conflict and we'll output the stage 1/2/3 information.
- a successful merge will output a single stage 0 ("merged") entry,
potentially for a whole subdirectory.
- it outputs all the resolve information on stdout, so something like the
recursive resolver can pretty easily parse it all.
Now, the caveats:
- we probably need to be more careful about subdirectory resolves. The
trivial case (both branches have the exact same subdirectory) is a
trivial resolve, but the other cases ("branch1 matches base, branch2 is
different" probably can't be silently just resolved to the "branch2"
subdirectory state, since it might involve renames into - or out of -
that subdirectory)
- we do not track the current index file at all, so this does not do the
"check that index matches branch1" logic that the three-way merge in
git-read-tree does. The theory is that we'd do a full three-way merge
(ignoring the index and working directory), and then to update the
working tree, we'd do a two-way "git-read-tree branch1->result"
- I didn't actually make it do all the trivial resolve cases that
git-read-tree does. It's a technology demonstration.
Finally (a more serious caveat):
- doing things through stdout may end up being so expensive that we'd
need to do something else. In particular, it's likely that I should
not actually output the "merge results", but instead output a "merge
results as they _differ_ from branch1"
However, I think this patch is already interesting enough that people who
are interested in merging trees might want to look at it. Please keep in
mind that tech _demo_ part, and in particular, keep in mind the final
"serious caveat" part.
In many ways, the really _interesting_ part of a merge is not the result,
but how it _changes_ the branch we're merging into. That's particularly
important as it should hopefully also mean that the output size for any
reasonable case is minimal (and tracks what we actually need to do to the
current state to create the final result).
The code very much is organized so that doing the result as a "diff
against branch1" should be quite easy/possible. I was actually going to do
it, but I decided that it probably makes the output harder to read. I
dunno.
Anyway, let's think about this kind of approach.. Note how the code itself
is actually quite small and short, although it's prbably pretty "dense".
As an interesting test-case, I'd suggest this merge in the kernel:
git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc
which resolves beautifully (there are no actual file-level conflicts), and
you can look at the output of that command to start thinking about what
it does.
The interesting part (perhaps) is that timing that command for me shows
that it takes all of 0.004 seconds.. (the git-merge-base thing takes
considerably more ;)
The point is, we _can_ do the actual merge part really really quickly.
Linus
PS. Final note: when I say that it is "WORKING CODE", that is obviously by
my standards. IOW, I tested it once and it gave reasonable results - so it
must be perfect.
Whether it works for anybody else, or indeed for any other test-case, is
not my problem ;)
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15 10:05:30 +08:00
|
|
|
|
2013-04-08 05:07:51 +08: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 10:05:30 +08:00
|
|
|
}
|
2006-02-16 11:25:32 +08:00
|
|
|
|
2008-03-06 10:59:29 +08:00
|
|
|
unresolved(info, entry);
|
2008-03-06 11:44:06 +08:00
|
|
|
return mask;
|
2006-02-16 11:25:32 +08:00
|
|
|
}
|
|
|
|
|
|
2022-06-18 08:20:44 +08:00
|
|
|
static void trivial_merge_trees(struct tree_desc t[3], const char *base)
|
2006-02-16 11:25:32 +08:00
|
|
|
{
|
2008-03-06 10:59:29 +08:00
|
|
|
struct traverse_info info;
|
|
|
|
|
|
|
|
|
|
setup_traverse_info(&info, base);
|
|
|
|
|
info.fn = threeway_callback;
|
2024-04-18 20:14:14 +08:00
|
|
|
traverse_trees(the_repository->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 10:05:30 +08:00
|
|
|
}
|
|
|
|
|
|
2019-06-27 17:28:48 +08: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 10:05:30 +08:00
|
|
|
{
|
2017-07-14 07:49:19 +08: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 10:05:30 +08:00
|
|
|
void *buf;
|
|
|
|
|
|
2019-06-27 17:28:48 +08:00
|
|
|
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 10:05:30 +08:00
|
|
|
die("unknown rev %s", rev);
|
2019-06-27 17:28:48 +08:00
|
|
|
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 10:05:30 +08:00
|
|
|
if (!buf)
|
|
|
|
|
die("%s is not a tree", rev);
|
|
|
|
|
return buf;
|
|
|
|
|
}
|
|
|
|
|
|
2022-06-18 08:20:46 +08:00
|
|
|
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 10:05:30 +08:00
|
|
|
{
|
2019-06-27 17:28:48 +08: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 10:05:30 +08:00
|
|
|
struct tree_desc t[3];
|
|
|
|
|
void *buf1, *buf2, *buf3;
|
|
|
|
|
|
2022-06-18 08:20:46 +08:00
|
|
|
buf1 = get_tree_descriptor(r, t+0, base);
|
|
|
|
|
buf2 = get_tree_descriptor(r, t+1, branch1);
|
|
|
|
|
buf3 = get_tree_descriptor(r, t+2, branch2);
|
2022-06-18 08:20:44 +08:00
|
|
|
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 10:05:30 +08: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-29 02:18:27 +08: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 10:05:30 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
2022-06-18 08:20:45 +08:00
|
|
|
|
2022-06-18 08:20:46 +08:00
|
|
|
enum mode {
|
|
|
|
|
MODE_UNKNOWN,
|
|
|
|
|
MODE_TRIVIAL,
|
|
|
|
|
MODE_REAL,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct merge_tree_options {
|
|
|
|
|
int mode;
|
2022-06-18 08:20:59 +08:00
|
|
|
int allow_unrelated_histories;
|
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 08:20:49 +08:00
|
|
|
int show_messages;
|
2022-06-18 08:20:53 +08:00
|
|
|
int name_only;
|
2022-10-23 09:28:05 +08:00
|
|
|
int use_stdin;
|
2023-09-24 10:23:42 +08:00
|
|
|
struct merge_options merge_options;
|
2022-06-18 08:20:46 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int real_merge(struct merge_tree_options *o,
|
2022-11-12 07:45:13 +08:00
|
|
|
const char *merge_base,
|
2022-06-18 08:20:52 +08:00
|
|
|
const char *branch1, const char *branch2,
|
|
|
|
|
const char *prefix)
|
2022-06-18 08:20:46 +08:00
|
|
|
{
|
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 08:20:47 +08:00
|
|
|
struct commit *parent1, *parent2;
|
|
|
|
|
struct commit_list *merge_bases = NULL;
|
|
|
|
|
struct merge_result result = { 0 };
|
2022-10-23 09:28:05 +08:00
|
|
|
int show_messages = o->show_messages;
|
2023-10-12 04:37:47 +08:00
|
|
|
struct merge_options opt;
|
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 08:20:47 +08:00
|
|
|
|
2023-10-12 04:37:47 +08:00
|
|
|
copy_merge_options(&opt, &o->merge_options);
|
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 08:20:47 +08:00
|
|
|
opt.show_rename_progress = 0;
|
|
|
|
|
|
|
|
|
|
opt.branch1 = branch1;
|
|
|
|
|
opt.branch2 = branch2;
|
|
|
|
|
|
2022-11-12 07:45:13 +08:00
|
|
|
if (merge_base) {
|
|
|
|
|
struct tree *base_tree, *parent1_tree, *parent2_tree;
|
|
|
|
|
|
2024-01-29 04:34:22 +08:00
|
|
|
/*
|
|
|
|
|
* We actually only need the trees because we already
|
|
|
|
|
* have a merge base.
|
|
|
|
|
*/
|
|
|
|
|
struct object_id base_oid, head_oid, merge_oid;
|
|
|
|
|
|
|
|
|
|
if (repo_get_oid_treeish(the_repository, merge_base, &base_oid))
|
|
|
|
|
die(_("could not parse as tree '%s'"), merge_base);
|
|
|
|
|
base_tree = parse_tree_indirect(&base_oid);
|
2024-02-23 16:34:23 +08:00
|
|
|
if (!base_tree)
|
|
|
|
|
die(_("unable to read tree (%s)"), oid_to_hex(&base_oid));
|
2024-01-29 04:34:22 +08:00
|
|
|
if (repo_get_oid_treeish(the_repository, branch1, &head_oid))
|
|
|
|
|
die(_("could not parse as tree '%s'"), branch1);
|
|
|
|
|
parent1_tree = parse_tree_indirect(&head_oid);
|
2024-02-23 16:34:23 +08:00
|
|
|
if (!parent1_tree)
|
|
|
|
|
die(_("unable to read tree (%s)"), oid_to_hex(&head_oid));
|
2024-01-29 04:34:22 +08:00
|
|
|
if (repo_get_oid_treeish(the_repository, branch2, &merge_oid))
|
|
|
|
|
die(_("could not parse as tree '%s'"), branch2);
|
|
|
|
|
parent2_tree = parse_tree_indirect(&merge_oid);
|
2024-02-23 16:34:23 +08:00
|
|
|
if (!parent2_tree)
|
|
|
|
|
die(_("unable to read tree (%s)"), oid_to_hex(&merge_oid));
|
2022-11-12 07:45:13 +08:00
|
|
|
|
|
|
|
|
opt.ancestor = merge_base;
|
|
|
|
|
merge_incore_nonrecursive(&opt, base_tree, parent1_tree, parent2_tree, &result);
|
|
|
|
|
} else {
|
2024-01-29 04:34:22 +08: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"));
|
|
|
|
|
|
2022-11-12 07:45:13 +08:00
|
|
|
/*
|
|
|
|
|
* Get the merge bases, in reverse order; see comment above
|
|
|
|
|
* merge_incore_recursive in merge-ort.h
|
|
|
|
|
*/
|
2024-02-28 17:44:14 +08:00
|
|
|
if (repo_get_merge_bases(the_repository, parent1,
|
|
|
|
|
parent2, &merge_bases) < 0)
|
|
|
|
|
exit(128);
|
2022-11-12 07:45:13 +08:00
|
|
|
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 08:20:47 +08:00
|
|
|
|
|
|
|
|
if (result.clean < 0)
|
|
|
|
|
die(_("failure to merge"));
|
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 08:20:49 +08:00
|
|
|
|
2022-10-23 09:28:05 +08:00
|
|
|
if (show_messages == -1)
|
|
|
|
|
show_messages = !result.clean;
|
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 08:20:49 +08:00
|
|
|
|
2022-10-23 09:28:05 +08:00
|
|
|
if (o->use_stdin)
|
|
|
|
|
printf("%d%c", result.clean, line_termination);
|
2022-06-18 08:20:58 +08:00
|
|
|
printf("%s%c", oid_to_hex(&result.tree->object.oid), line_termination);
|
2022-06-18 08:20:52 +08:00
|
|
|
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;
|
2022-06-18 08:20:53 +08:00
|
|
|
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))
|
2022-06-18 08:20:52 +08:00
|
|
|
continue;
|
|
|
|
|
write_name_quoted_relative(
|
|
|
|
|
name, prefix, stdout, line_termination);
|
|
|
|
|
last = name;
|
|
|
|
|
}
|
|
|
|
|
string_list_clear(&conflicted_files, 1);
|
|
|
|
|
}
|
2022-10-23 09:28:05 +08:00
|
|
|
if (show_messages) {
|
2022-06-18 08:20:52 +08:00
|
|
|
putchar(line_termination);
|
2022-06-18 08:20:57 +08:00
|
|
|
merge_display_update_messages(&opt, line_termination == '\0',
|
|
|
|
|
&result);
|
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 08:20:49 +08:00
|
|
|
}
|
2022-10-23 09:28:05 +08:00
|
|
|
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 08:20:47 +08:00
|
|
|
merge_finalize(&opt, &result);
|
2023-10-12 04:37:47 +08:00
|
|
|
clear_merge_options(&opt);
|
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 08:20:47 +08:00
|
|
|
return !result.clean; /* result.clean < 0 handled above */
|
2022-06-18 08:20:46 +08:00
|
|
|
}
|
|
|
|
|
|
2022-06-18 08:20:45 +08:00
|
|
|
int cmd_merge_tree(int argc, const char **argv, const char *prefix)
|
|
|
|
|
{
|
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 08:20:49 +08:00
|
|
|
struct merge_tree_options o = { .show_messages = -1 };
|
2023-09-24 10:23:42 +08:00
|
|
|
struct strvec xopts = STRVEC_INIT;
|
2022-06-18 08:20:46 +08:00
|
|
|
int expected_remaining_argc;
|
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 08:20:49 +08:00
|
|
|
int original_argc;
|
2022-11-12 07:45:13 +08:00
|
|
|
const char *merge_base = NULL;
|
2022-06-18 08:20:46 +08:00
|
|
|
|
|
|
|
|
const char * const merge_tree_usage[] = {
|
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 08:20:49 +08:00
|
|
|
N_("git merge-tree [--write-tree] [<options>] <branch1> <branch2>"),
|
2022-06-18 08:20:46 +08:00
|
|
|
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),
|
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 08:20:49 +08:00
|
|
|
OPT_BOOL(0, "messages", &o.show_messages,
|
|
|
|
|
N_("also show informational/conflict messages")),
|
2022-06-18 08:20:58 +08:00
|
|
|
OPT_SET_INT('z', NULL, &line_termination,
|
|
|
|
|
N_("separate paths with the NUL character"), '\0'),
|
2022-06-18 08:20:53 +08:00
|
|
|
OPT_BOOL_F(0, "name-only",
|
|
|
|
|
&o.name_only,
|
|
|
|
|
N_("list filenames without modes/oids/stages"),
|
|
|
|
|
PARSE_OPT_NONEG),
|
2022-06-18 08:20:59 +08:00
|
|
|
OPT_BOOL_F(0, "allow-unrelated-histories",
|
|
|
|
|
&o.allow_unrelated_histories,
|
|
|
|
|
N_("allow merging unrelated histories"),
|
|
|
|
|
PARSE_OPT_NONEG),
|
2022-10-23 09:28:05 +08:00
|
|
|
OPT_BOOL_F(0, "stdin",
|
|
|
|
|
&o.use_stdin,
|
|
|
|
|
N_("perform multiple merges, one per line of input"),
|
|
|
|
|
PARSE_OPT_NONEG),
|
2022-11-12 07:45:13 +08:00
|
|
|
OPT_STRING(0, "merge-base",
|
|
|
|
|
&merge_base,
|
2024-04-12 20:10:40 +08:00
|
|
|
N_("tree-ish"),
|
2022-11-12 07:45:13 +08:00
|
|
|
N_("specify a merge-base for the merge")),
|
2023-09-24 10:23:42 +08:00
|
|
|
OPT_STRVEC('X', "strategy-option", &xopts, N_("option=value"),
|
|
|
|
|
N_("option for selected merge strategy")),
|
2022-06-18 08:20:46 +08:00
|
|
|
OPT_END()
|
|
|
|
|
};
|
|
|
|
|
|
2023-09-24 10:23:42 +08:00
|
|
|
/* Init merge options */
|
|
|
|
|
init_merge_options(&o.merge_options, the_repository);
|
|
|
|
|
|
2022-06-18 08:20:46 +08:00
|
|
|
/* Parse arguments */
|
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 08:20:49 +08:00
|
|
|
original_argc = argc - 1; /* ignoring argv[0] */
|
2022-06-18 08:20:46 +08:00
|
|
|
argc = parse_options(argc, argv, prefix, mt_options,
|
|
|
|
|
merge_tree_usage, PARSE_OPT_STOP_AT_NON_OPTION);
|
2022-10-23 09:28:05 +08:00
|
|
|
|
2023-09-24 10:23:42 +08:00
|
|
|
if (xopts.nr && o.mode == MODE_TRIVIAL)
|
|
|
|
|
die(_("--trivial-merge is incompatible with all other options"));
|
|
|
|
|
for (int x = 0; x < xopts.nr; x++)
|
|
|
|
|
if (parse_merge_opt(&o.merge_options, xopts.v[x]))
|
|
|
|
|
die(_("unknown strategy option: -X%s"), xopts.v[x]);
|
|
|
|
|
|
2022-10-23 09:28:05 +08:00
|
|
|
/* 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"));
|
2022-11-12 07:45:13 +08:00
|
|
|
if (merge_base)
|
2023-11-26 19:57:43 +08:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"),
|
|
|
|
|
"--merge-base", "--stdin");
|
2022-10-23 09:28:05 +08:00
|
|
|
line_termination = '\0';
|
|
|
|
|
while (strbuf_getline_lf(&buf, stdin) != EOF) {
|
|
|
|
|
struct strbuf **split;
|
|
|
|
|
int result;
|
2022-11-12 07:45:14 +08:00
|
|
|
const char *input_merge_base = NULL;
|
2022-10-23 09:28:05 +08:00
|
|
|
|
|
|
|
|
split = strbuf_split(&buf, ' ');
|
2022-11-12 07:45:14 +08:00
|
|
|
if (!split[0] || !split[1])
|
2022-10-23 09:28:05 +08:00
|
|
|
die(_("malformed input line: '%s'."), buf.buf);
|
|
|
|
|
strbuf_rtrim(split[0]);
|
2022-11-12 07:45:14 +08:00
|
|
|
strbuf_rtrim(split[1]);
|
|
|
|
|
|
|
|
|
|
/* parse the merge-base */
|
|
|
|
|
if (!strcmp(split[1]->buf, "--")) {
|
|
|
|
|
input_merge_base = split[0]->buf;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (input_merge_base && split[2] && split[3] && !split[4]) {
|
|
|
|
|
strbuf_rtrim(split[2]);
|
|
|
|
|
strbuf_rtrim(split[3]);
|
|
|
|
|
result = real_merge(&o, input_merge_base, split[2]->buf, split[3]->buf, prefix);
|
|
|
|
|
} else if (!input_merge_base && !split[2]) {
|
|
|
|
|
result = real_merge(&o, NULL, split[0]->buf, split[1]->buf, prefix);
|
|
|
|
|
} else {
|
|
|
|
|
die(_("malformed input line: '%s'."), buf.buf);
|
|
|
|
|
}
|
|
|
|
|
|
2022-10-23 09:28:05 +08:00
|
|
|
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 */
|
2022-06-18 08:20:46 +08:00
|
|
|
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;
|
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 08:20:49 +08:00
|
|
|
/* Removal of `--trivial-merge` is expected */
|
|
|
|
|
original_argc--;
|
2022-06-18 08:20:46 +08:00
|
|
|
break;
|
|
|
|
|
}
|
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 08:20:49 +08:00
|
|
|
if (o.mode == MODE_TRIVIAL && argc < original_argc)
|
|
|
|
|
die(_("--trivial-merge is incompatible with all other options"));
|
2022-06-18 08:20:46 +08:00
|
|
|
|
|
|
|
|
if (argc != expected_remaining_argc)
|
|
|
|
|
usage_with_options(merge_tree_usage, mt_options);
|
|
|
|
|
|
2023-05-11 03:07:34 +08:00
|
|
|
git_config(git_default_config, NULL);
|
|
|
|
|
|
2022-06-18 08:20:46 +08:00
|
|
|
/* Do the relevant type of merge */
|
|
|
|
|
if (o.mode == MODE_REAL)
|
2022-11-12 07:45:13 +08:00
|
|
|
return real_merge(&o, merge_base, argv[0], argv[1], prefix);
|
2022-06-18 08:20:46 +08:00
|
|
|
else
|
|
|
|
|
return trivial_merge(argv[0], argv[1], argv[2]);
|
2022-06-18 08:20:45 +08:00
|
|
|
}
|
