summaryrefslogtreecommitdiff
path: root/t/t6023-merge-rename-nocruft.sh
AgeCommit message (Collapse)AuthorFilesLines
2009-03-14test-suite: Make test script numbers uniqueLibravatar Johannes Sixt1-139/+0
In order to selectively skip tests, the environment variable GIT_SKIP_TESTS can be set like this: $ GIT_SKIP_TESTS='t1301 t4150.18' make test That is, its value can contain only the test script numbers, but not the full script name. Therefore, it is important that the test scripts are uniquely numbered. This makes it so. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-02-03Keep untracked files not involved in a merge.Libravatar Shawn O. Pearce1-0/+42
My earlier fix (8371234e) to delete renamed tracked files from the working directory also caused merge-recursive to delete untracked files that were in the working directory. The problem here is merge-recursive is deleting the working directory file without regard for which branch it was associated with. What we really want to do during a merge is to only delete files that were renamed by the branch we are merging into the current branch, and that are still tracked by the current branch. These files definitely don't belong in the working directory anymore. Anything else is either a merge conflict (already handled in other parts of the code) or a file that is untracked by the current branch and thus is not even participating in the merge. Its this latter class that must be left alone. For this fix to work we are now assuming that the first non-base argument passed to git-merge-recursive always corresponds to the working directory. This is already true for all in-tree callers of merge-recursive. This assumption is also supported by the long time usage message of "<base> ... -- <head> <remote>", where "<head>" is implied to be HEAD, which is generally assumed to be the current tree-ish. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-13Remove uncontested renamed files during merge.Libravatar Shawn Pearce1-0/+97
Prior to 65ac6e9c3f47807cb603af07a6a9e1a43bc119ae we deleted a file from the working directory during a merge if the file existed before the merge started but was renamed by the branch being merged in. This broke in 65ac6e as git-merge-recursive did not actually update the working directory on an uncontested rename. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>