Re: reftable progress

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

 



Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes:

> Hi folks,
>
> I have some alpha-quality code for Reftable support in Git at
>
>  https://github.com/hanwen/git/tree/reftable
>
> I'd be curious for some feedback, both on the library
> (https://github.com/google/reftable) and the glue code in Git.

If you are asking for feedback, sendign it over to this list with 
[RFC PATCH n/3]  as the subject prefix would have better chance.

I have a feeling that the patch to show-ref is done at the wrong
level.  The show_ref() function is given as the callback function
to head_ref() and for_each_ref(), and the way these functions call
the callback function is part of the ref API.  "In the reftable
format, ... are stored in the reference database too," is perfectly
fine (that is the implementation detail of the ref API backend) but
"and are produced when iterating over the refs" is not.  Hide that
inside the ref API backend you are writing for reftable and this
change will become unnecessary.

I agree with the general direction of the second patch that extends
setup.c to allow .git/refs to be a regular file to signal that the
repository is using reftable (instead of filesystem-based refs), but
the title "fix repo detection" is misleading---it is adjusting for
the new format (as there is nothing to "fix" if there weren't the
new format).  Also, the actual implementation may want to be a bit
more strict, i.e. saying "we allow refs/ to be a searchable
directory, and we also allow a readable regular file".

Thanks.





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

  Powered by Linux