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: Tue, 27 Sep 2011 17:58:43 -0400 [thread overview]
Message-ID: <20110927215843.GE5176@sigill.intra.peff.net> (raw)
In-Reply-To: <4E7DEC4A.3050900@drmicha.warpmail.net>
On Sat, Sep 24, 2011 at 04:42:18PM +0200, Michael J Gruber wrote:
> > 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.
>
> [mjg@localhost git]$ git rev-parse ref:mjg/vob/virtual-objects
> 3f8aa9bb80fe241306aafd3d76af50739ba88268
> [mjg@localhost git]$ git show 3f8aa9bb80fe241306aafd3d76af50739ba88268
> refs/heads/mjg/vob/virtual-objects
Sure, but what about:
git notes list
which is just filled with meaningless nonsense.
> > 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)
>
> Given the above, I don't think it's more friendly.
>
> In fact, in my first attempt, I wrote out the blobs, and referenced them
> just like above from a different subtree within the notes tree, in order
> to keep them from being pruned. So the virtual approach is pretty
> equivalent, though leaner.
Hmm. So your mapping of $ref to $desc is:
sha1($ref) -> sha1(blob($desc))
>From what you wrote there, I think maybe you think I meant to store:
sha1(blob($ref)) -> sha1(blob($desc))
But what I meant was actually:
$ref -> sha1(blob($desc))
I.e., not to use "notes" at all, but rather a tree that mirrors the
refs/ hierarchy in its names.
> > 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.
>
> Well, "git branch --edit-description" and such should be the way to edit
> them, shouldn't it?
It's one way. I assume that if we store things in a reasonable,
readable state, then people like that because they can hack on the data
structure using more flexible tools.
> I really think the only issue is remote refnames. As Junio points out,
> they are local by nature. OTOH, you typically use a non-renaming refspec
> which puts them under refs/remotes/foo/bar with "bar" being the same
> name as the local one on the remote, foo something you have chosen. So,
> teaching the code that the note for
If they are local by nature, is it worth putting them into a notes tree
at all? That provides versioning and backup. But I wonder if it is worth
the hassle, when one could just put them in the config.
-Peff
next prev parent reply other threads:[~2011-09-27 21:58 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
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 [this message]
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=20110927215843.GE5176@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).