git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).