git-add: no need for -f when resolving a conflict in already tracked path
authorJeff King <peff@peff.net>
Sat, 30 May 2009 21:54:18 +0000 (17:54 -0400)
committerJunio C Hamano <gitster@pobox.com>
Sun, 31 May 2009 22:59:16 +0000 (15:59 -0700)
commit6e4f981ffb88c8a9d3d6128314f4dd4f54ffb8a8
tree46b7c19d0fdcc6c9634c0aea2b95cf6219c95487
parent13bd21340888de1fab7d745fc447bb43694a20c5
git-add: no need for -f when resolving a conflict in already tracked path

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>
dir.c
t/t3700-add.sh