git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH 0/6] A handful of "branch description" patches
Date: Fri, 23 Sep 2011 16:18:24 -0400	[thread overview]
Message-ID: <20110923201824.GA27999@sigill.intra.peff.net> (raw)
In-Reply-To: <4E7C49CF.60508@drmicha.warpmail.net>

On Fri, Sep 23, 2011 at 10:56:47AM +0200, Michael J Gruber wrote:

>   mjg/vob/refrev-pretend [mjg/vob/virtual-objects: ahead 1]
>     Pseudo revs for refnames
>     
>     An alternative implementation using pretend_sha1...
>     Currently unused.
> 
>   mjg/vob/virtual-objects [origin/next: ahead 2, behind 10]
>     Virtual refname objects
>     
>     For each existing refname, introduce virtual objects corresponding to a blob
>     with the refname as the content. "virtual" refers to the fact that these
>     objects are not written out but exist for all other purposes, such as
>     attaching notes and keeping them from being pruned.

Eww. :)

This seems like a clever solution to making git-notes store a ref as a
key instead of an arbitrary sha1. But I wonder if the end result is
really waht the user wants. The resulting notes tree is good for doing
lookups, but the entries are completely obfuscated. So I can't easily do
something like "list all of the refs which have descriptions". I can
only list the _hashes_ of the refs which have descriptions. And if I am
lucky, I can hash the refs I have and correlate them. But unknown ones
will simply be a mystery.

Wouldn't it be much more friendly to have a separate tree of refnames
that stores:

  refs/heads/foo -> (some blob with the "foo" description)
  refs/heads/bar -> (some blob with the "bar" description)

Yeah, you have to build another git-notes-like interface around it. But
the data structure is pleasant and flexible. You could even "git
checkout" the whole tree and edit the notes with your editor, without
having to deal with some obfuscated name.

-Peff

  reply	other threads:[~2011-09-23 20:18 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-13 16:45 [Survey] Signed push Junio C Hamano
2011-09-13 22:28 ` [PATCH v2 0/2] State commit name explicitly in request-pull messages Junio C Hamano
2011-09-13 22:28   ` [PATCH v2 1/2] fetch: allow asking for an explicit commit object by name Junio C Hamano
2011-09-13 22:28   ` [PATCH v2 2/2] request-pull: state exact commit object name Junio C Hamano
2011-09-13 23:26 ` [Survey] Signed push Guenter Roeck
2011-09-13 23:50   ` Junio C Hamano
2011-09-14  0:02     ` Junio C Hamano
2011-09-14  0:31 ` Sam Vilain
2011-09-14  0:39   ` Shawn Pearce
2011-09-14  1:03     ` Sam Vilain
     [not found] ` <CA+55aFxAQTR3sT7gekAD4qih8J+z-qwri7ZmNCPUd811xgci6w@mail.gmail.com>
2011-09-14  7:06   ` Fwd: " Linus Torvalds
2011-09-14 10:45     ` Michael Haggerty
2011-09-14 11:03       ` Matthieu Moy
2011-09-14 11:46         ` Nguyen Thai Ngoc Duy
2011-09-14 12:28         ` Johan Herland
2011-09-14 12:56           ` Ted Ts'o
2011-09-14 15:27         ` Linus Torvalds
2011-09-14 15:42           ` Matthieu Moy
2011-09-14 16:14           ` Johan Herland
2011-09-14 22:51             ` Philip Oakley
2011-09-14 23:30               ` Linus Torvalds
2011-09-14 23:44                 ` Junio C Hamano
2011-09-14 15:25       ` Linus Torvalds
2011-09-14 17:52         ` Junio C Hamano
2011-09-14 18:36           ` Linus Torvalds
2011-09-14 17:49     ` Junio C Hamano
2011-09-14 20:52       ` Sam Vilain
2011-09-16 19:04       ` [PATCH v3] request-pull: state what commit to expect Junio C Hamano
2011-09-20 23:01         ` Junio C Hamano
2011-09-20 23:02           ` [PATCH 2/3] branch: teach --edit-description option Junio C Hamano
2011-09-21  0:15             ` Andrew Ardill
2011-09-21  2:44               ` Junio C Hamano
2011-09-20 23:03           ` [PATCH] request-pull: use the branch description Junio C Hamano
2011-09-22 22:09           ` [PATCH 0/6] A handful of "branch description" patches Junio C Hamano
2011-09-22 22:09             ` [PATCH 1/6] branch: add read_branch_desc() helper function Junio C Hamano
2011-09-22 22:09             ` [PATCH 2/6] format-patch: use branch description in cover letter Junio C Hamano
2011-09-22 22:09             ` [PATCH 3/6] branch: teach --edit-description option Junio C Hamano
2011-09-23  9:00               ` Michael J Gruber
2011-09-23  9:47               ` Nguyen Thai Ngoc Duy
2011-09-23 19:04                 ` Junio C Hamano
2011-09-25  5:21                   ` Nguyen Thai Ngoc Duy
2011-09-22 22:09             ` [PATCH 4/6] request-pull: modernize style Junio C Hamano
2011-09-22 22:09             ` [PATCH 5/6] request-pull: state what commit to expect Junio C Hamano
2011-09-22 22:09             ` [PATCH 6/6] request-pull: use the branch description Junio C Hamano
2011-09-23  8:56             ` [PATCH 0/6] A handful of "branch description" patches Michael J Gruber
2011-09-23 20:18               ` Jeff King [this message]
2011-09-23 20:52                 ` Junio C Hamano
2011-09-23 20:53                   ` Jeff King
2011-09-24 14:42                 ` Michael J Gruber
2011-09-27 21:58                   ` Jeff King
2011-09-28  4:23                     ` Annotated branch ≈ annotated tag? Michael Haggerty
2011-09-28  7:12                       ` Andrew Ardill
2011-09-28  8:04                         ` Michael Haggerty
2011-09-28  8:58                           ` Branch annotations [Re: Annotated branch ≈ annotated tag?] Michael J Gruber
2011-09-29  6:44                       ` Annotated branch ≈ annotated tag? Jeff King
2011-09-14 11:58 ` [Survey] Signed push Nguyen Thai Ngoc Duy
2011-09-14 21:05   ` Jonathan Nieder
2011-09-14 22:42     ` Nguyen Thai Ngoc Duy
2011-09-15 17:50       ` Jeff King
2011-09-14 19:35 ` Andy Lutomirski
2011-09-14 20:40   ` Junio C Hamano
2011-09-14 20:49     ` Andrew Lutomirski

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=20110923201824.GA27999@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).