René Scharfe wrote:
Mark Levedahl schrieb:
git>git bisect good
6490a3383f1d0d96c122069e510ef1af1d019fbb is first bad commit
I've started a bisect run myself and ended up at a different commit,
viz. e90fdc39b6903502192b2dd11e5503cea721a1ad ("Clean up work-tree
handling"). Hmm. I guess this candidate has a greater chance of
actually being the culprit than yours. ;-)
Nak - at commit e90fdc... it works fine for me here. However, one
problem is the following lines in setup.c/set_work_tree() that appear
until 6490a3
strncpy(dir_buffer, dir, len - postfix_len);
/* are we inside the default work tree? */
rel = get_relative_cwd(buffer, sizeof(buffer), dir_buffer);
Note that dir_buffer is not null terminated in the above code, that bug
has been around for a while, and you certainly could run into a
different problem than I did as the results are essentially undefined
here because of that bug.. The key innovation for the current discussion
in commit 6490a33 is that dir_buffer is null terminated after the copy,
causing a different but repeatable result from get_relative_cwd.
I think this ultimately exposes a bug in
builtin-checkout-index/checkout_all wherein the latter does not
explicitly honor the given --prefix option that is passed along in
state. Specifically, on each pass the following test passes
if (prefix && *prefix &&
(ce_namelen(ce) <= prefix_length ||
memcmp(prefix, ce->name, prefix_length)))
continue;
so the code never attempts to write the file out. I cannot fathom what
this test is trying to discern and have to leave it to others more
familiar with the design to figure out the right course. For this
particular use, the passed in prefix is irrelevant, the correct path to
write to is in state.
Mark
-
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
