When a path F that matches ignore pattern has a conflict, "git add F"
insisted the -f option be given, which did not make sense. It would have
required -f when the path was originally added, but when resolving a
conflict, it already is tracked.
So this should work (and does):
$ echo file >.gitignore
$ echo content >file
$ git add -f file ;# need -f because we are adding new path
$ echo more content >>file
$ git add file ;# don't need -f; it is not actually an "other" file
This is handled under the hood by the COLLECT_IGNORED option to
read_directory. When that code finds an ignored file, it checks the
index to make sure it is not actually a tracked file. However, the test
it uses does not take into account unmerged entries, and considers them
to still be ignored. "git ls-files" uses a more elaborate test and gets
the right answer and the same test should be used here.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
static struct dir_entry *dir_add_ignored(struct dir_struct *dir, const char *pathname, int len)
{
- if (cache_name_pos(pathname, len) >= 0)
+ if (!cache_name_is_other(pathname, len))
return NULL;
ALLOC_GROW(dir->ignored, dir->ignored_nr+1, dir->ignored_alloc);
! ( git ls-files foobar | grep foobar )
'
+test_expect_success 'git add to resolve conflicts on otherwise ignored path' '
+ git reset --hard &&
+ H=$(git rev-parse :1/2/a) &&
+ (
+ echo "100644 $H 1 track-this"
+ echo "100644 $H 3 track-this"
+ ) | git update-index --index-info &&
+ echo track-this >>.gitignore &&
+ echo resolved >track-this &&
+ git add track-this
+'
+
test_done