From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Seymour Subject: Re: A generalization of git notes from blobs to trees - git metadata? Date: Sun, 7 Feb 2010 20:41:02 +1100 Message-ID: <2cfc40321002070141y36f62679id6ce72f924a635de@mail.gmail.com> References: <2cfc40321002060532g4d22dd4dx403bf312708e1424@mail.gmail.com> <201002070236.12711.johan@herland.net> <7v1vgxlr9q.fsf@alter.siamese.dyndns.org> <20100207050255.GA17049@coredump.intra.peff.net> <2cfc40321002062136q64f832aesd979c9cb22f3612@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeff King , Junio C Hamano , Johan Herland , git@vger.kernel.org To: Jakub Narebski X-From: git-owner@vger.kernel.org Sun Feb 07 10:41:21 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ne3dh-0007wi-0k for gcvg-git-2@lo.gmane.org; Sun, 07 Feb 2010 10:41:13 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753510Ab0BGJlH (ORCPT ); Sun, 7 Feb 2010 04:41:07 -0500 Received: from mail-pz0-f187.google.com ([209.85.222.187]:38952 "EHLO mail-pz0-f187.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753077Ab0BGJlE (ORCPT ); Sun, 7 Feb 2010 04:41:04 -0500 Received: by pzk17 with SMTP id 17so1208190pzk.4 for ; Sun, 07 Feb 2010 01:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=od20pprHNOlCw9n027cp6EKVRCqMv1kOym7ZUhfh9IQ=; b=T2JXEx3M36KL7guorU0zmPYbfl51n35GN0m4fGkrSbe3hEX5h7P2bg17qeE3FBIxYd CD1MrsGZhpCW4YMKZfyhe/PX2u6HUKwSB1XQ4GoJ5THfjDV0AjafdU8rq6fW84TCX4wS ubBWg3kpiUyGSrOco2cwrAxih8aFFeR6bwnjg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JZcrR0c/161dUuGhaPcJu2YDbtWJdXrW0eGkCxtoFQJz5hH/5eo1R5vbD1l9UAma06 vRLYv1Xjm+SONMJd8jYRqtncChg/Kfu7Spesesrq6y9f8zzM8jPKF/p/ZyQQ0JmYGPdK Z8GDWJCe6DvU+owgwEdXrIUJA/rSQcW6LRF6g= Received: by 10.114.189.24 with SMTP id m24mr3391071waf.126.1265535662728; Sun, 07 Feb 2010 01:41:02 -0800 (PST) In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Sun, Feb 7, 2010 at 8:15 PM, Jakub Narebski wrote: > Jon Seymour 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.