hoi :)
On Thu, Jun 01, 2006 at 09:21:38AM -0700, Linus Torvalds wrote:
> Those files were _never_ tracked.
You are right, I used the wrong demonstration to show my problem.
I had one problem like this in the linux-kernel and tried to
reproduce them in the git repository but did it wrong...
GIT reset seems to have a problem when a file is tracked and ignored
at the same time.
This fails:
diff --git a/t/t7101-reset.sh b/t/t7101-reset.sh
index a919140..865e0f6 100755
--- a/t/t7101-reset.sh
+++ b/t/t7101-reset.sh
@@ -21,10 +21,12 @@ test_expect_success \
cp ../../COPYING path1/COPYING &&
cp ../../COPYING COPYING &&
cp ../../COPYING path0/COPYING-TOO &&
+ echo COPYING > .gitignore &&
git-add path1/path2/COPYING &&
git-add path1/COPYING &&
git-add COPYING &&
git-add path0/COPYING-TOO &&
+ git-add .gitignore &&
git-commit -m change -a'
test_expect_success \
This hit me as the Linux kernel .gitignore includes ".*" which matches
all the .gitignore files and so they are not removed when you go
back to 2.6.13. But with the new git checks regarding files in
the working dir, git then refuses to pull in newer Linux versions
because it would overwrite ".gitignore".
--
Martin Waitz
Attachment:
signature.asc
Description: Digital signature