summaryrefslogtreecommitdiff
path: root/t/t4300-merge-tree.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-10-12leak tests: mark some misc tests as passing with SANITIZE=leakLibravatar Ævar Arnfjörð Bjarmason1-0/+2
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>
2020-01-15t4300: abstract away SHA-1-specific constantsLibravatar brian m. carlson1-94/+94
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>
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'Libravatar SZEDER Gábor1-27/+7
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>
2013-05-06merge-tree: handle directory/empty conflict correctlyLibravatar John Keeping1-0/+51
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-04-28merge-tree: fix typo in "both changed identically"Libravatar John Keeping1-0/+13
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-08merge-tree: don't print entries that match "local"Libravatar John Keeping1-10/+0
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>
2012-12-26merge-tree: fix d/f conflictsLibravatar Junio C Hamano1-2/+2
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-26merge-tree: add comments to clarify what these functions are doingLibravatar Junio C Hamano1-0/+44
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>
2010-07-14merge-tree: fix where two branches share no changesLibravatar Will Palmer1-3/+3
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-14add basic tests for merge-treeLibravatar Will Palmer1-0/+257
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>