Duy Nguyen <pclouds@xxxxxxxxx> writes:
> On Tue, Sep 23, 2014 at 2:15 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> When we have a/b/c and a/d/e to be written, the first round would
>> write a/ and then a/b/ with the above, and presumably elsewhere
>> somebody will write a/b/c; next time around we do need to write a/d/
>> but we wouldn't want to write a/ itself. How is this code
>> preventing the recursion going all the way up every time to avoid
>> repeating a/?
>>
>> Puzzled...
>
> We never traverse 'a' (or any directory) twice and we only push a
> directory to the stack when we examine it. After a/b and a are written
> down and we examine 'd', 'a/d' is pushed to the stack. When we hit
> 'a/d/e', we only have 'a/d' in the stack, not 'a'.
So the traverser will feed you
a/
a/b/
a/b/c
a/d/
a/d/e
in that order, and you keep a/ and a/b/ until you see a/b/c at which
time you flush the two queued ones and likewise for a/d/ and a/d/e.
When you queue a/d/ you do not decompose that to a/ and a/d/ because
you know that the caller of the callback would have made sure all
the leading path components have been given you by the time it gave
you a/d/, and it all works out fine.
Thanks for clarifying.
--
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