On Thu, Oct 16, 2008 at 02:30:00PM +0200, Lars Hoss wrote:
> The commit was on Jun 5, 14:47:50 by Marius Storm-Olsen and the relevant
> file is wt-status.c.
>
> Ok, I think I found the issue. I enabled showUntrackedFiles in my gitconfig:
>
> status.showUntrackedFiles = all
Ah, OK. I see what is going on. All code paths call the read_directory
infrastructure to find untracked files. If status.showUntrackedFiles is
"normal", then we set dir.show_other_directories, to indicate that we
want to see the directories, but not their constituent files.
If status.showuntrackedfiles is set to "all", then we don't set the
show_other_directories flag, because we want each file. But the code in
dir.c:treat_directory uses the "show_other_directories" flag to say "oh,
we're just interested in untracked files" and decide whether to ignore
gitlinks.
Meaning that we must still filter the results of read_directory based on
the cache. And indeed, this is what "git ls-files -o" does, as explained
in 5698454e (Fix some "git ls-files -o" fallout from gitlinks). It's
also what the code in wt_status_print_untracked is _supposed_ to do, but
it was never updated to handle this case when git-ls-files was. Which is
probably my fault a long time ago for cutting and pasting the 5 lines of
"is this thing in the cache" when writing wt-status.c.
So the quick fix is to re-cut-and-paste the code:
diff --git a/wt-status.c b/wt-status.c
index d2eac36..792d5f1 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -280,10 +280,14 @@ static void wt_status_print_untracked(struct wt_status *s)
/* check for matching entry, which is unmerged; lifted from
* builtin-ls-files:show_other_files */
struct dir_entry *ent = dir.entries[i];
- int pos = cache_name_pos(ent->name, ent->len);
+ int len, pos;
+ len = ent->len;
+ if (len && ent->name[len-1] == '/')
+ len--;
+ pos = cache_name_pos(ent->name, len);
struct cache_entry *ce;
if (0 <= pos)
- die("bug in wt_status_print_untracked");
+ continue;
pos = -pos - 1;
if (pos < active_nr) {
ce = active_cache[pos];
But the right solution is to refactor this so the code isn't duplicated.
And I'll post a patch for that in a second.
I do have to wonder, though, whether an even better solution would be to
more explicitly tell read_directory "I'm interested only in 'other'
files" rather than relying on guessing based on
dir.show_other_directories. Then we could just avoid ever passing these
gitlinks back to ls-files and status in the first place.
-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
