There seems to be a bug in "git-status" in next (but not in master). I
bisected it to:
commit d1f2d7e8ca65504722108e2db710788f66c34c6c
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Sat Jan 19 17:27:12 2008 -0800
Make run_diff_index() use unpack_trees(), not read_tree()
Basically, doing a partial commit when a new file has been added to the
index but isn't part of the partial commit will cause that new file to
be listed as part of the index. You can reproduce it with:
mkdir trash && cd trash && git init &&
touch file && git add file && git commit -m one &&
touch added && git add added &&
echo modified >file && git status file
Even more exciting, the later commit cf558704 causes an infinite loop
(but still has the bad behavior), which is then fixed in 9cb76b8c (which
still has the bad behavior, in addition to printing the "bug in
wt_status_print_untracked" message to indicate that we found something
funny in the index).
I _think_ of all of this is caused by the fact that builtin-commit looks
in the regular index, but then gives us an alternate index. This didn't
matter before because we were discarding the index so many time anyway.
The patch below fixes it by discarding and re-reading the index if we
are doing a partial commit, but I suspect it may just be papering over
the problem again. We probably need to have two separate index_states,
and pass in the correct one to wt-status (rather than giving it the
filename and having it read into the_index).
diff --git a/builtin-commit.c b/builtin-commit.c
index c63ff82..005362e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -313,6 +313,10 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&false_lock))
die("unable to write temporary index file");
+
+ discard_cache();
+ read_cache_from(false_lock.filename);
+
return false_lock.filename;
}
-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
