Commit Graph

13 Commits

Author SHA1 Message Date
John Keeping
ab5f42422d merge-tree: fix typo in "both changed identically"
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 <rene.scharfe@lsrfire.ath.cx>
Test-written-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-28 11:53:41 -07:00
John Keeping
aacecc3b36 merge-tree: don't print entries that match "local"
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 <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-08 10:50:52 -07:00
John Keeping
187c00c6c5 merge-tree: fix typo in merge-tree.c::unresolved
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 <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27 10:00:50 -07:00
Junio C Hamano
35ffe75831 merge-tree: fix d/f conflicts
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 <gitster@pobox.com>
2012-12-26 14:46:15 -08:00
Junio C Hamano
8dd15c6a90 merge-tree: add comments to clarify what these functions are doing
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 <gitster@pobox.com>
2012-12-26 14:46:15 -08:00
Junio C Hamano
3b8ff51b70 merge-tree: lose unused "resolve_directories"
This option is always set; simplify.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-26 14:45:12 -08:00
Junio C Hamano
b13112fa16 merge-tree: lose unused "flags" from merge_list
Drop the unused field from the structure.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-26 14:44:47 -08:00
Junio C Hamano
fa2364ec34 Which merge_file() function do you mean?
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 <gitster@pobox.com>
2012-12-09 23:05:27 -08:00
Ramsay Jones
1e0f8c41ac sparse: Fix an "symbol 'merge_file' not decared" warning
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 <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-11 10:35:25 -07:00
Stephen Boyd
c2e86addb8 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 10:16:54 -07:00
Will Palmer
21baa6e0c5 merge-tree: fix where two branches share no changes
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 <wmpalmer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-14 12:56:49 -07:00
Junio C Hamano
60335534a6 Merge branch 'rs/diff-no-minimal' into maint
* rs/diff-no-minimal:
  git diff too slow for a file
2010-06-21 05:38:50 -07:00
Linus Torvalds
81b50f3ce4 Move 'builtin-*' into a 'builtin/' subdirectory
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 <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22 14:29:41 -08:00