git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen R. van den Berg" <srb@cuci.nl>
To: Jan Hudec <bulb@ucw.cz>
Cc: david@lang.hm, "Shawn O. Pearce" <spearce@spearce.org>,
	Scott Chacon <schacon@gmail.com>, Jamey Sharp <jamey@minilop.net>,
	Josh Triplett <josh@freedesktop.org>,
	git@vger.kernel.org
Subject: Re: [RFC] Plumbing-only support for storing object metadata
Date: Sun, 10 Aug 2008 19:57:35 +0200	[thread overview]
Message-ID: <20080810175735.GA14237@cuci.nl> (raw)
In-Reply-To: <20080810145019.GC3955@efreet.light.src>

Jan Hudec wrote:
>On Sun, Aug 10, 2008 at 05:16:47 -0700, david@lang.hm wrote:
>> On Sun, 10 Aug 2008, Stephen R. van den Berg wrote:
>>> However, pondering the idea a bit more, I could envision something
>>> similar to the following:

>.... provided the two entries under the same name wouldn't drive the internal
>logic completely mad, I quite like this. Note by the way, that you need to
>allow for two trees too, because you may want to store attributes for

Well, in theory yes, but currently git doesn't store directories.
How about extending git-core to allow for storage of directories by
virtue of the following object in a tree:

040000 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391  .

I.e. the hash belongs to the empty blob.
Normally you don't (have to) store these directory blobs, but if you
insist on having them, git will create the empty directory on checkout
(i.e. you wouldn't need the dummy file trick anymore to force the
directory to be present).
-- 
Sincerely,
           Stephen R. van den Berg.

Real programmers don't produce results, they return exit codes.

  reply	other threads:[~2008-08-10 17:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-09 21:07 [RFC] Plumbing-only support for storing object metadata Jamey Sharp, Josh Triplett
2008-08-09 21:49 ` Scott Chacon
2008-08-10  3:51   ` Shawn O. Pearce
2008-08-10 11:20     ` Stephen R. van den Berg
2008-08-10 12:16       ` david
2008-08-10 14:50         ` Jan Hudec
2008-08-10 17:57           ` Stephen R. van den Berg [this message]
2008-08-10 18:11             ` Jan Hudec
2008-08-10 20:16               ` Stephen R. van den Berg
2008-08-10 22:34                 ` Junio C Hamano
2008-08-10 23:10                   ` david
2008-08-11 10:11                     ` Stephen R. van den Berg
2008-08-16  6:21                 ` Josh Triplett, Jamey Sharp
2008-08-16  7:56                   ` david
2008-08-16  9:55                   ` Junio C Hamano
2008-08-16 15:07                     ` Jan Hudec
2008-08-18  6:12                   ` Shawn O. Pearce
2008-08-18 23:06                     ` Derek Fawcus
2008-08-18 23:18                       ` Shawn O. Pearce
2008-08-18 23:23                       ` Marcus Griep
2008-08-18 23:28                         ` Shawn O. Pearce
2008-08-10 11:09 ` Jan Hudec

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=20080810175735.GA14237@cuci.nl \
    --to=srb@cuci.nl \
    --cc=bulb@ucw.cz \
    --cc=david@lang.hm \
    --cc=git@vger.kernel.org \
    --cc=jamey@minilop.net \
    --cc=josh@freedesktop.org \
    --cc=schacon@gmail.com \
    --cc=spearce@spearce.org \
    /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).