Commit Graph

10 Commits

Author SHA1 Message Date
Ævar Arnfjörð Bjarmason
7ff24785cb leak tests: mark some misc tests as passing with SANITIZE=leak
Mark some tests that match "*{mktree,commit,diff,grep,rm,merge,hunk}*"
as passing when git is compiled with SANITIZE=leak. They'll now be
listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test
mode (the "linux-leaks" CI target).

These were picked because we still have a lot of failures in adjacent
areas, and we didn't have much if any coverage of e.g. grep and diff
before this change, we could still whitelist a lot more tests, but
let's stop for now.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12 18:23:24 -07:00
brian m. carlson
525a7f1769 t4300: abstract away SHA-1-specific constants
Adjust the test so that it computes values for object IDs instead of
using hard-coded hashes.  Move the heredocs later in the tests so we can
take advantage of computed values.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15 14:06:19 -08:00
SZEDER Gábor
1c5e94f459 tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'
Using 'test_must_be_empty' is shorter and more idiomatic than

  >empty &&
  test_cmp empty out

as it saves the creation of an empty file.  Furthermore, sometimes the
expected empty file doesn't have such a descriptive name like 'empty',
and its creation is far away from the place where it's finally used
for comparison (e.g. in 't7600-merge.sh', where two expected empty
files are created in the 'setup' test, but are used only about 500
lines later).

These cases were found by instrumenting 'test_cmp' to error out the
test script when it's used to compare empty files, and then converted
manually.

Note that even after this patch there still remain a lot of cases
where we use 'test_cmp' to check empty files:

  - Sometimes the expected output is not hard-coded in the test, but
    'test_cmp' is used to ensure that two similar git commands produce
    the same output, and that output happens to be empty, e.g. the
    test 'submodule update --merge  - ignores --merge  for new
    submodules' in 't7406-submodule-update.sh'.

  - Repetitive common tasks, including preparing the expected results
    and running 'test_cmp', are often extracted into a helper
    function, and some of this helper's callsites expect no output.

  - For the same reason as above, the whole 'test_expect_success'
    block is within a helper function, e.g. in 't3070-wildmatch.sh'.

  - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update
    (-p)' in 't9400-git-cvsserver-server.sh'.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-21 11:48:36 -07:00
John Keeping
94883b4302 merge-tree: handle directory/empty conflict correctly
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 <andreas@andreasjacobsen.com>
Signed-off-by: John Keeping <john@keeping.me.uk>
Tested-by: Andreas Jacobsen <andreas@andreasjacobsen.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-06 22:17:00 -07:00
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
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
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
Will Palmer
f32e9852d4 add basic tests for merge-tree
merge-tree had no test cases, so here we add some very basic tests for
it, including some known-breakages.

[jc: with obvious/trivial fixups]

Signed-off-by: Will Palmer <wmpalmer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-14 12:55:15 -07:00