Re: [PATCH v2 01/20] get_ref_dir(): don't call read_loose_refs() for "refs/bisect"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 31, 2017 at 7:10 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote:
> Since references under "refs/bisect/" are per-worktree, they have to
> be sought in the worktree rather than in the main repository. But
> since loose references are found by traversing directories, the
> reference iterator won't even get the idea to look for a
> "refs/bisect/" directory in the worktree if there is not a directory
> with that name in the main repository. Thus `get_ref_dir()` manually
> inserts a dir_entry for "refs/bisect/" whenever it reads the entry for
> "refs/".
>
> The current code then immediately calls `read_loose_refs()` on that
> directory. But since the dir_entry is created with its `incomplete`
> flag set, any traversal that gets to this point will read the
> directory automatically. So there is no need to call
> `read_loose_refs()` explicitly; the lazy mechanism suffices.
>
> And in fact, the attempt to `read_loose_refs()` was broken anyway.
> That function needs its `dirname` argument to have a trailing `/`
> character, but the invocation here was passing it "refs/bisect"
> without a trailing slash. So `read_loose_refs()` would read
> `$GIT_DIR/refs/bisect" correctly, but if it found an entry "foo" in
> that directory, it would try to read "$GIT_DIR/refs/bisectfoo".
> Normally it wouldn't find anything at that path, but the failure was
> canceled out because `get_ref_dir()` *also* forgot to reset the
> `REF_INCOMPLETE` bit on the dir_entry. So the read was attempted again
> when it was accessed, via the lazy mechanism, and this time the read
> was done correctly.

With all this retry logic going on, it is hard to add a test demonstrating
this is correct now. The description makes sense though.

Thanks,
Stefan



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]