2018-07-31 20:12:04 +03:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='Test various callers of read_index_unmerged'
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_expect_success 'setup modify/delete + directory/file conflict' '
|
|
|
|
test_create_repo df_plus_modify_delete &&
|
|
|
|
(
|
|
|
|
cd df_plus_modify_delete &&
|
|
|
|
|
|
|
|
test_write_lines a b c d e f g h >letters &&
|
|
|
|
git add letters &&
|
|
|
|
git commit -m initial &&
|
|
|
|
|
|
|
|
git checkout -b modify &&
|
|
|
|
# Throw in letters.txt for sorting order fun
|
|
|
|
# ("letters.txt" sorts between "letters" and "letters/file")
|
|
|
|
echo i >>letters &&
|
|
|
|
echo "version 2" >letters.txt &&
|
|
|
|
git add letters letters.txt &&
|
|
|
|
git commit -m modified &&
|
|
|
|
|
|
|
|
git checkout -b delete HEAD^ &&
|
|
|
|
git rm letters &&
|
|
|
|
mkdir letters &&
|
|
|
|
>letters/file &&
|
|
|
|
echo "version 1" >letters.txt &&
|
|
|
|
git add letters letters.txt &&
|
|
|
|
git commit -m deleted
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
read-cache: fix directory/file conflict handling in read_index_unmerged()
read_index_unmerged() has two intended purposes:
* return 1 if there are any unmerged entries, 0 otherwise
* drops any higher-stage entries down to stage #0
There are several callers of read_index_unmerged() that check the return
value to see if it is non-zero, all of which then die() if that condition
is met. For these callers, dropping higher-stage entries down to stage #0
is a waste of resources, and returning immediately on first unmerged entry
would be better. But it's probably only a very minor difference and isn't
the focus of this series.
The remaining callers ignore the return value and call this function for
the side effect of dropping higher-stage entries down to stage #0. As
mentioned in commit e11d7b596970 ("'reset --merge': fix unmerged case",
2009-12-31),
The _only_ reason we want to keep a previously unmerged entry in the
index at stage #0 is so that we don't forget the fact that we have
corresponding file in the work tree in order to be able to remove it
when the tree we are resetting to does not have the path.
In fact, prior to commit d1a43f2aa4bf ("reset --hard/read-tree --reset -u:
remove unmerged new paths", 2008-10-15), read_index_unmerged() did just
remove unmerged entries from the cache immediately but that had the
unwanted effect of leaving around new untracked files in the tree from
aborted merges.
So, that's the intended purpose of this function. The problem is that
when directory/files conflicts are present, trying to add the file to the
index at stage 0 fails (because there is still a directory in the way),
and the function returns early with a -1 return code to signify the error.
As noted above, none of the callers who want the drop-to-stage-0 behavior
check the return status, though, so this means all remaining unmerged
entries remain in the index and the callers proceed assuming otherwise.
Users then see errors of the form:
error: 'DIR-OR-FILE' appears as both a file and as a directory
error: DIR-OR-FILE: cannot drop to stage #0
and potentially also messages about other unmerged entries which came
lexicographically later than whatever pathname was both a file and a
directory. Google finds a few hits searching for those messages,
suggesting there were probably a couple people who hit this besides me.
Luckily, calling `git reset --hard` multiple times would workaround
this bug.
Since the whole purpose here is to just put the entry *temporarily* into
the index so that any associated file in the working copy can be removed,
we can just skip the DFCHECK and allow both the file and directory to
appear in the index. The temporary simultaneous appearance of the
directory and file entries in the index will be removed by the callers
by calling unpack_trees(), which excludes these unmerged entries marked
with CE_CONFLICTED flag from the resulting index, before they attempt to
write the index anywhere.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-31 20:12:05 +03:00
|
|
|
test_expect_success 'read-tree --reset cleans unmerged entries' '
|
2018-07-31 20:12:04 +03:00
|
|
|
test_when_finished "git -C df_plus_modify_delete clean -f" &&
|
|
|
|
test_when_finished "git -C df_plus_modify_delete reset --hard" &&
|
|
|
|
(
|
|
|
|
cd df_plus_modify_delete &&
|
|
|
|
|
|
|
|
git checkout delete^0 &&
|
|
|
|
test_must_fail git merge modify &&
|
|
|
|
|
|
|
|
git read-tree --reset HEAD &&
|
|
|
|
git ls-files -u >conflicts &&
|
|
|
|
test_must_be_empty conflicts
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
read-cache: fix directory/file conflict handling in read_index_unmerged()
read_index_unmerged() has two intended purposes:
* return 1 if there are any unmerged entries, 0 otherwise
* drops any higher-stage entries down to stage #0
There are several callers of read_index_unmerged() that check the return
value to see if it is non-zero, all of which then die() if that condition
is met. For these callers, dropping higher-stage entries down to stage #0
is a waste of resources, and returning immediately on first unmerged entry
would be better. But it's probably only a very minor difference and isn't
the focus of this series.
The remaining callers ignore the return value and call this function for
the side effect of dropping higher-stage entries down to stage #0. As
mentioned in commit e11d7b596970 ("'reset --merge': fix unmerged case",
2009-12-31),
The _only_ reason we want to keep a previously unmerged entry in the
index at stage #0 is so that we don't forget the fact that we have
corresponding file in the work tree in order to be able to remove it
when the tree we are resetting to does not have the path.
In fact, prior to commit d1a43f2aa4bf ("reset --hard/read-tree --reset -u:
remove unmerged new paths", 2008-10-15), read_index_unmerged() did just
remove unmerged entries from the cache immediately but that had the
unwanted effect of leaving around new untracked files in the tree from
aborted merges.
So, that's the intended purpose of this function. The problem is that
when directory/files conflicts are present, trying to add the file to the
index at stage 0 fails (because there is still a directory in the way),
and the function returns early with a -1 return code to signify the error.
As noted above, none of the callers who want the drop-to-stage-0 behavior
check the return status, though, so this means all remaining unmerged
entries remain in the index and the callers proceed assuming otherwise.
Users then see errors of the form:
error: 'DIR-OR-FILE' appears as both a file and as a directory
error: DIR-OR-FILE: cannot drop to stage #0
and potentially also messages about other unmerged entries which came
lexicographically later than whatever pathname was both a file and a
directory. Google finds a few hits searching for those messages,
suggesting there were probably a couple people who hit this besides me.
Luckily, calling `git reset --hard` multiple times would workaround
this bug.
Since the whole purpose here is to just put the entry *temporarily* into
the index so that any associated file in the working copy can be removed,
we can just skip the DFCHECK and allow both the file and directory to
appear in the index. The temporary simultaneous appearance of the
directory and file entries in the index will be removed by the callers
by calling unpack_trees(), which excludes these unmerged entries marked
with CE_CONFLICTED flag from the resulting index, before they attempt to
write the index anywhere.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-31 20:12:05 +03:00
|
|
|
test_expect_success 'One reset --hard cleans unmerged entries' '
|
2018-07-31 20:12:04 +03:00
|
|
|
test_when_finished "git -C df_plus_modify_delete clean -f" &&
|
|
|
|
test_when_finished "git -C df_plus_modify_delete reset --hard" &&
|
|
|
|
(
|
|
|
|
cd df_plus_modify_delete &&
|
|
|
|
|
|
|
|
git checkout delete^0 &&
|
|
|
|
test_must_fail git merge modify &&
|
|
|
|
|
|
|
|
git reset --hard &&
|
|
|
|
test_path_is_missing .git/MERGE_HEAD &&
|
|
|
|
git ls-files -u >conflicts &&
|
|
|
|
test_must_be_empty conflicts
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'setup directory/file conflict + simple edit/edit' '
|
|
|
|
test_create_repo df_plus_edit_edit &&
|
|
|
|
(
|
|
|
|
cd df_plus_edit_edit &&
|
|
|
|
|
|
|
|
test_seq 1 10 >numbers &&
|
|
|
|
git add numbers &&
|
|
|
|
git commit -m initial &&
|
|
|
|
|
|
|
|
git checkout -b d-edit &&
|
|
|
|
mkdir foo &&
|
|
|
|
echo content >foo/bar &&
|
|
|
|
git add foo &&
|
|
|
|
echo 11 >>numbers &&
|
|
|
|
git add numbers &&
|
|
|
|
git commit -m "directory and edit" &&
|
|
|
|
|
|
|
|
git checkout -b f-edit d-edit^1 &&
|
|
|
|
echo content >foo &&
|
|
|
|
git add foo &&
|
|
|
|
echo eleven >>numbers &&
|
|
|
|
git add numbers &&
|
|
|
|
git commit -m "file and edit"
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
read-cache: fix directory/file conflict handling in read_index_unmerged()
read_index_unmerged() has two intended purposes:
* return 1 if there are any unmerged entries, 0 otherwise
* drops any higher-stage entries down to stage #0
There are several callers of read_index_unmerged() that check the return
value to see if it is non-zero, all of which then die() if that condition
is met. For these callers, dropping higher-stage entries down to stage #0
is a waste of resources, and returning immediately on first unmerged entry
would be better. But it's probably only a very minor difference and isn't
the focus of this series.
The remaining callers ignore the return value and call this function for
the side effect of dropping higher-stage entries down to stage #0. As
mentioned in commit e11d7b596970 ("'reset --merge': fix unmerged case",
2009-12-31),
The _only_ reason we want to keep a previously unmerged entry in the
index at stage #0 is so that we don't forget the fact that we have
corresponding file in the work tree in order to be able to remove it
when the tree we are resetting to does not have the path.
In fact, prior to commit d1a43f2aa4bf ("reset --hard/read-tree --reset -u:
remove unmerged new paths", 2008-10-15), read_index_unmerged() did just
remove unmerged entries from the cache immediately but that had the
unwanted effect of leaving around new untracked files in the tree from
aborted merges.
So, that's the intended purpose of this function. The problem is that
when directory/files conflicts are present, trying to add the file to the
index at stage 0 fails (because there is still a directory in the way),
and the function returns early with a -1 return code to signify the error.
As noted above, none of the callers who want the drop-to-stage-0 behavior
check the return status, though, so this means all remaining unmerged
entries remain in the index and the callers proceed assuming otherwise.
Users then see errors of the form:
error: 'DIR-OR-FILE' appears as both a file and as a directory
error: DIR-OR-FILE: cannot drop to stage #0
and potentially also messages about other unmerged entries which came
lexicographically later than whatever pathname was both a file and a
directory. Google finds a few hits searching for those messages,
suggesting there were probably a couple people who hit this besides me.
Luckily, calling `git reset --hard` multiple times would workaround
this bug.
Since the whole purpose here is to just put the entry *temporarily* into
the index so that any associated file in the working copy can be removed,
we can just skip the DFCHECK and allow both the file and directory to
appear in the index. The temporary simultaneous appearance of the
directory and file entries in the index will be removed by the callers
by calling unpack_trees(), which excludes these unmerged entries marked
with CE_CONFLICTED flag from the resulting index, before they attempt to
write the index anywhere.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-31 20:12:05 +03:00
|
|
|
test_expect_success 'git merge --abort succeeds despite D/F conflict' '
|
2018-07-31 20:12:04 +03:00
|
|
|
test_when_finished "git -C df_plus_edit_edit clean -f" &&
|
|
|
|
test_when_finished "git -C df_plus_edit_edit reset --hard" &&
|
|
|
|
(
|
|
|
|
cd df_plus_edit_edit &&
|
|
|
|
|
|
|
|
git checkout f-edit^0 &&
|
|
|
|
test_must_fail git merge d-edit^0 &&
|
|
|
|
|
|
|
|
git merge --abort &&
|
|
|
|
test_path_is_missing .git/MERGE_HEAD &&
|
|
|
|
git ls-files -u >conflicts &&
|
|
|
|
test_must_be_empty conflicts
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
read-cache: fix directory/file conflict handling in read_index_unmerged()
read_index_unmerged() has two intended purposes:
* return 1 if there are any unmerged entries, 0 otherwise
* drops any higher-stage entries down to stage #0
There are several callers of read_index_unmerged() that check the return
value to see if it is non-zero, all of which then die() if that condition
is met. For these callers, dropping higher-stage entries down to stage #0
is a waste of resources, and returning immediately on first unmerged entry
would be better. But it's probably only a very minor difference and isn't
the focus of this series.
The remaining callers ignore the return value and call this function for
the side effect of dropping higher-stage entries down to stage #0. As
mentioned in commit e11d7b596970 ("'reset --merge': fix unmerged case",
2009-12-31),
The _only_ reason we want to keep a previously unmerged entry in the
index at stage #0 is so that we don't forget the fact that we have
corresponding file in the work tree in order to be able to remove it
when the tree we are resetting to does not have the path.
In fact, prior to commit d1a43f2aa4bf ("reset --hard/read-tree --reset -u:
remove unmerged new paths", 2008-10-15), read_index_unmerged() did just
remove unmerged entries from the cache immediately but that had the
unwanted effect of leaving around new untracked files in the tree from
aborted merges.
So, that's the intended purpose of this function. The problem is that
when directory/files conflicts are present, trying to add the file to the
index at stage 0 fails (because there is still a directory in the way),
and the function returns early with a -1 return code to signify the error.
As noted above, none of the callers who want the drop-to-stage-0 behavior
check the return status, though, so this means all remaining unmerged
entries remain in the index and the callers proceed assuming otherwise.
Users then see errors of the form:
error: 'DIR-OR-FILE' appears as both a file and as a directory
error: DIR-OR-FILE: cannot drop to stage #0
and potentially also messages about other unmerged entries which came
lexicographically later than whatever pathname was both a file and a
directory. Google finds a few hits searching for those messages,
suggesting there were probably a couple people who hit this besides me.
Luckily, calling `git reset --hard` multiple times would workaround
this bug.
Since the whole purpose here is to just put the entry *temporarily* into
the index so that any associated file in the working copy can be removed,
we can just skip the DFCHECK and allow both the file and directory to
appear in the index. The temporary simultaneous appearance of the
directory and file entries in the index will be removed by the callers
by calling unpack_trees(), which excludes these unmerged entries marked
with CE_CONFLICTED flag from the resulting index, before they attempt to
write the index anywhere.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-31 20:12:05 +03:00
|
|
|
test_expect_success 'git am --skip succeeds despite D/F conflict' '
|
2018-07-31 20:12:04 +03:00
|
|
|
test_when_finished "git -C df_plus_edit_edit clean -f" &&
|
|
|
|
test_when_finished "git -C df_plus_edit_edit reset --hard" &&
|
|
|
|
(
|
|
|
|
cd df_plus_edit_edit &&
|
|
|
|
|
|
|
|
git checkout f-edit^0 &&
|
|
|
|
git format-patch -1 d-edit &&
|
|
|
|
test_must_fail git am -3 0001*.patch &&
|
|
|
|
|
|
|
|
git am --skip &&
|
|
|
|
test_path_is_missing .git/rebase-apply &&
|
|
|
|
git ls-files -u >conflicts &&
|
|
|
|
test_must_be_empty conflicts
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
|
|
|
test_done
|