From: Mark Levedahl Date: Sat, 04 Aug 2007 20:45:54 GMT Subject: Re: rc4 - make quick-install-doc is broken Message-ID: <46B4E582.7030200@gmail.com> In-Reply-To: <46B4DF39.2070506@lsrfire.ath.cx> 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