Re: [PATCHv5 00/14] git notes

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

 



On Sep 7, 2009, at 22:26, Johan Herland wrote:
Yet another iteration of the 'git notes' feature. Rebased on top of 'next': - Patches 1-9 are unchanged from (patches 1-7, 11-12 of) the last iteration. - Patch 10 teaches the notes code to free its data structures on request. - Patch 11 introduces the 16-tree notes lookup code that handles SHA1-based fanout schemes. This is pretty much unchanged from patch 8 in the previous
 iteration.
- Patch 12 adds selftests that verify correct parsing of notes trees with
 various SHA1-based fanouts.
- Patch 13 introduces a flexible parser for a variety of date-based and SHA1-based fanout schemes. This is the interesting part, as far as this
 iteration is concerned.
- Patch 14 adds selftests that verify correct parsing of notes trees with
 various date-based fanouts.

Note that the series does not yet include code for _writing_ notes into a suitably structured notes tree. That will be done in a later iteration.

I have some performance numbers that I will send in a separate email.

Hi Johan,

I've been following this series with some interest, and am curious
why notes need to be stored in a separate data structure from regular
objects. Note that I'm not questioning the design (and certainly would
not want to, this late in the process), rather I'd like to learn
about the reasons.

I've wondered about this as well in the context of refs, reflog and
git config. In a completely unified model, every change to the
repository (except  for the index, pack indices and working directory)
would be a  commit of the .git/ directory (again excluding indices).
One of the advantages (besides allowing configuration management
of the repository itself in addition to its contents) would be that
no locking is ever required.

This would be just an implementation detail without necessarily
affecting the user interface other than direct inspection/modification
of the .git directory, which is a similar to the move to packed refs.
Again, I'm not proposing to change anything, just wondering about
design rationale.

  -Geert
--
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

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