Jeff King <peff@xxxxxxxx> writes:
> On Thu, Sep 13, 2012 at 12:40:39PM -0700, Junio C Hamano wrote:
>
>> > Interesting. I don't get any such warning on repack. And RelNotes points
>> > to a file, so I'm not sure why stat() would make us think it was a dir.
>>
>> Interesting. The command in question is
>>
>> git-pack-objects --keep-true-parents --honor-pack-keep --non-empty \
>> --all --reflog --delta-base-offset </dev/null .junk-pack
>
> Weird. I don't see any problems with that command, either (I tried it
> with the current 'next'). Thinking that maybe delta reuse was getting in
> the way, I also tried it with --no-reuse-delta.
>
>> - "rev-list --object --all" does not produce "Relnotes/1.7.4.txt"
>> (it does have "Documentation/RelNotes/1.7.4.txt", of course).
>> Somebody in this callchain is screwing the name up.
>
> Yeah, that sounds like a pretty huge bug. But since I can't reproduce,
> you're on your own for tracking it down.
I have a remote tracking branch refs/remotes/repo/html that has the
path RelNotes/1.7.4.txt at the top ;-) Depending on how traversal
goes, if the tree that represents that RelNotes directory in the html
tree is found before the tree that represents Documentation/RelNotes
directory in the main history at the corresponding commit, it is
perfectly normal that we discover the blob as RelNotes/1.7.4.txt, so
there is no bug.
So among the three points I raised, the first one was a false issue,
the second one is real (we do look for attributes in the working
tree for historical commit, or for a commit that does not belong to
the same lineage as the one that is currently checked out, hence we
must ignore ENOTDIR), and the third one is unrelated.
> I think that this:
>
>> diff --git i/attr.c w/attr.c
>> index f12c83f..056d702 100644
>> --- i/attr.c
>> +++ w/attr.c
>> @@ -353,7 +353,7 @@ static struct attr_stack *read_attr_from_file(const char *path, int macro_ok)
>> int lineno = 0;
>>
>> if (!fp) {
>> - if (errno != ENOENT)
>> + if (errno != ENOENT && errno != ENOTDIR)
>> warn_on_inaccessible(path);
>> return NULL;
>> }
>
> is the right thing to do. It's cool that it uncovered a bug in this
> case, but it is easy to construct a non-bug case that would exhibit the
> same bogus warning (just convert a directory into a file).
Yes.
--
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