Re: rc4 - make quick-install-doc is broken

[Mark Levedahl <mlevedahl@gmail.com>]

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