From: Jon Seymour <jon.seymour@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>,
Johan Herland <johan@herland.net>,
git@vger.kernel.org
Subject: Re: A generalization of git notes from blobs to trees - git metadata?
Date: Sun, 7 Feb 2010 20:41:02 +1100 [thread overview]
Message-ID: <2cfc40321002070141y36f62679id6ce72f924a635de@mail.gmail.com> (raw)
In-Reply-To: <m363699zn4.fsf@localhost.localdomain>
On Sun, Feb 7, 2010 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> 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? :-)
>
No I am not. I don't see why a metadata proposal is any more exposed
to subversive payloads than say, use of git merge -s ours [ a
subversive payload could be made reachable from a commit that
otherwise merges in favour of the legitimate source - who would know?
]
Really, I can't see why the rationale that makes a single blob used
for extending a commit message justified can't be used to justify
associating a metadata tree of arbitrary complexity to an arbitrary
sha1 object. What makes maintaining a mapping to a single blob
acceptable but maintaining a mapping to a tree unacceptable? Is there
really any fundamental difference?
jon.
next prev parent reply other threads:[~2010-02-07 9:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-06 13:32 A generalization of git notes from blobs to trees - git metadata? Jon Seymour
2010-02-07 1:36 ` Johan Herland
2010-02-07 2:21 ` Junio C Hamano
2010-02-07 5:02 ` Jeff King
2010-02-07 5:36 ` Jon Seymour
2010-02-07 9:15 ` Jakub Narebski
2010-02-07 9:41 ` Jon Seymour [this message]
2010-02-07 10:15 ` Jon Seymour
2010-02-07 19:33 ` Jeff King
2010-02-07 20:25 ` Junio C Hamano
2010-02-08 2:03 ` Steven E. Harris
2010-02-10 5:09 ` Jeff King
2010-02-10 5:23 ` Junio C Hamano
2010-02-10 5:29 ` Jeff King
2010-02-07 18:48 ` Junio C Hamano
2010-02-07 19:18 ` Jeff King
2010-02-07 22:46 ` Johan Herland
2010-02-07 3:27 ` Jon Seymour
2010-02-07 4:32 ` Jon Seymour
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2cfc40321002070141y36f62679id6ce72f924a635de@mail.gmail.com \
--to=jon.seymour@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=johan@herland.net \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).