Re: A generalization of git notes from blobs to trees - git metadata?

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

 



Jon Seymour <jon.seymour@xxxxxxxxx> writes:

[cut]

> As I see it, the existing use of notes is a special instance of a more
> general metadata capability in which the metadata is constrained to be
> a single blob. If notes continued to be constrained in this way, there
> is no reason to change anything with respect to its current userspace
> behaviour. That said, most of the plumbing which enabled notes could
> be generalized to enable the arbitrary tree case [ which admittedly, I
> have yet to sell successfully !]
> 
> In one sense, there is a sense in the merge issue doesn't exist. When
> the maintainer publishes a tag no-one expects to have to deal with
> downstream conflicting definitions of the tag. Likewise, if the
> maintainer were to publish the /man and /html metadata trees (per my
> previous example) for a release tag, anyone who received
> /refs/metadata/doc would expect to receive the metadata trees as
> published by the maintainer. Anyone who didn't wouldn't have to pull
> /refs/metadata/doc.
> 
> I can see there are use cases where multiple parties might want to
> contribute metadata and I do not currently have a good solution to
> that problem, but that is not to say there isn't one - surely it is
> just a question of applying a little intellect creatively?

Are you trying to repeat fail of Apple's / MacOS / HFS+ filesystem
data/resource forks, and Microsoft's Alternate Data Streams in git? :-)

-- 
Jakub Narebski
Poland
ShadeHawk on #git
--
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]