Re: reversion in GIT_COMMON_DIR refs path

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

 



On Fri, May 19, 2017 at 9:37 PM, Joey Hess <id@xxxxxxxxxx> wrote:
> Joey Hess wrote:
>> Bisecting this test suite failure
>> https://git-annex.branchable.com/git-annex_in_nixpkgs_fails_with_git-2.13.0/
>> I landed on commit f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0 to git.
>>
>> It seems that changed resolving refs paths when GIT_DIR and GIT_COMMON_DIR
>> are both set. While before refs were looked for in GIT_COMMON_DIR,
>> now they're not.
>
> In case there's any doubt about whether this is a reversion or an
> intentional change, see gitrepository-layout(5):
>
>        refs
>            References are stored in subdirectories of this directory. The git
>            prune command knows to preserve objects reachable from refs found
>            in this directory and its subdirectories. This directory is ignored
>            if $GIT_COMMON_DIR is set and "$GIT_COMMON_DIR/refs" will be used
>            instead.
>
> So the documented behavior is broken.

It's a gray area. When I wrote that I think I forgot about
per-worktree refs (refs/bisect/*) so "This directory is ignored" is
not completely true. The final line (probably won't help you much) is
"per-repo refs must be read from $GIT_COMMON_DIR/refs, per-worktree
from $GIT_DIR". The fact that we looked per-repo (like master) in
$GIT_DIR is probably an unwanted side effect.
-- 
Duy



[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]