path: root/builtin/merge-tree.c
AgeCommit message (Collapse)Author
2013-05-07merge-tree: handle directory/empty conflict correctlyJohn Keeping
git-merge-tree causes a null pointer dereference when a directory entry exists in only one or two of the three trees being compared with no corresponding entry in the other tree(s). When this happens, we want to handle the entry as a directory and not attempt to mark it as a file merge. Do this by setting the entries bit in the directory mask when the entry is missing or when it is a directory, only performing the file comparison when we know that a file entry exists. Reported-by: Andreas Jacobsen <> Signed-off-by: John Keeping <> Tested-by: Andreas Jacobsen <> Signed-off-by: Junio C Hamano <>
2013-04-28merge-tree: fix typo in "both changed identically"John Keeping
Commit aacecc3 (merge-tree: don't print entries that match "local" - 2013-04-07) had a typo causing the "same in both" check to be incorrect and check if both the base and "their" versions are removed instead of checking that both the "our" and "their" versions are removed. Fix this. Reported-by: René Scharfe <> Test-written-by: René Scharfe <> Signed-off-by: John Keeping <> Signed-off-by: Junio C Hamano <>
2013-04-08merge-tree: don't print entries that match "local"John Keeping
The documentation says: the output from the command omits entries that match the <branch1> tree. But currently "added in branch1" and "removed in branch1" (both while unchanged in branch2) do print output. Change this so that the behaviour matches the documentation. Signed-off-by: John Keeping <> Signed-off-by: Junio C Hamano <>
2013-03-27merge-tree: fix typo in merge-tree.c::unresolvedJohn Keeping
When calculating whether there is a d/f conflict, the calculation of whether both sides are directories generates an incorrect references mask because it does not use the loop index to set the correct bit. Fix this typo. Signed-off-by: John Keeping <> Signed-off-by: Junio C Hamano <>
2012-12-26merge-tree: fix d/f conflictsJunio C Hamano
The previous commit documented two known breakages revolving around a case where one side flips a tree into a blob (or vice versa), where the original code simply gets confused and feeds a mixture of trees and blobs into either the recursive merge-tree (and recursing into the blob will fail) or three-way merge (and merging tree contents together with blobs will fail). Fix it by feeding trees (and only trees) into the recursive merge-tree machinery and blobs (and only blobs) into the three-way content level merge machinery separately; when this happens, the entire merge has to be marked as conflicting at the structure level. Signed-off-by: Junio C Hamano <>
2012-12-26merge-tree: add comments to clarify what these functions are doingJunio C Hamano
Rename the "branch1" parameter given to resolve() to "ours", to clarify what is going on. Also, annotate the unresolved_directory() function with some comments to show what decisions are made in each step, and highlight two bugs that need to be fixed. Add two tests to t4300 to illustrate these bugs. Signed-off-by: Junio C Hamano <>
2012-12-26merge-tree: lose unused "resolve_directories"Junio C Hamano
This option is always set; simplify. Signed-off-by: Junio C Hamano <>
2012-12-26merge-tree: lose unused "flags" from merge_listJunio C Hamano
Drop the unused field from the structure. Signed-off-by: Junio C Hamano <>
2012-12-10Which merge_file() function do you mean?Junio C Hamano
There are two different static functions and one global function, all of them called "merge_file()", with different signatures and purposes. Rename them all to reduce confusion in "git grep" output: * Rename the static one in merge-index to "merge_one_path(const char *path)" as that function is about asking an external command to resolve conflicts in one path. * Rename the global one in merge-file.c that is only used by merge-tree to "merge_blobs()", as the function takes three blobs and returns the merged result only in-core, without doing anything to the filesystem. * Rename the one in merge-recursive to "merge_one_file()", just to be fair. Also rename merge-file.[ch] to merge-blobs.[ch]. Signed-off-by: Junio C Hamano <>
2011-04-11sparse: Fix an "symbol 'merge_file' not decared" warningRamsay Jones
In order to fix the warning, we add a new "merge-file.h" header containing the extern declaration of the merge_file() function, and include the header in the source files that require the declaration. Signed-off-by: Ramsay Jones <> Signed-off-by: Junio C Hamano <>
2011-03-22Fix sparse warningsStephen Boyd
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 <> Signed-off-by: Junio C Hamano <>
2010-07-14merge-tree: fix where two branches share no changesWill Palmer
15b4f7a (merge-tree: use ll_merge() not xdl_merge(), 2010-01-16) introduced a regression to merge-tree to cause it to segfault when merging files which existed in one branch, but not in the other or in the merge-base. This was caused by referencing entry->path at a time when entry was known to be possibly-NULL. To correct the problem, we save the path of the entry we came in with, as the path should be the same among all the stages no matter which sides are involved in the merge. Signed-off-by: Will Palmer <> Signed-off-by: Junio C Hamano <>
2010-06-21Merge branch 'rs/diff-no-minimal' into maintJunio C Hamano
* rs/diff-no-minimal: git diff too slow for a file
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLinus Torvalds
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>