From: Michael J Gruber <git@drmicha•warpmail.net>
To: Jeff King <peff@peff•net>
Cc: Junio C Hamano <gitster@pobox•com>, git@vger•kernel.org
Subject: Re: [PATCH 0/6] A handful of "branch description" patches
Date: Sat, 24 Sep 2011 16:42:18 +0200 [thread overview]
Message-ID: <4E7DEC4A.3050900@drmicha.warpmail.net> (raw)
In-Reply-To: <20110923201824.GA27999@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 23.09.2011 22:18:
> 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.
[mjg@localhost git]$ git rev-parse ref:mjg/vob/virtual-objects
3f8aa9bb80fe241306aafd3d76af50739ba88268
[mjg@localhost git]$ git show 3f8aa9bb80fe241306aafd3d76af50739ba88268
refs/heads/mjg/vob/virtual-objects
:)
The only problem is with notes for non-existing refs. [You only have to
invoke the inverse mapping to sha1, of course... Uhm.]
> 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.
> 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?
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
refs/remotes/foo/bar
is in the notes tree
refs/remotes/foo/notes/commits (or .../refames, or whatever we do with
the namespaces)
as a note attached to sha1("refs/bar")
is really a non-issue. It's not done yet, in part because of the
possible namespace restructuring.
Michael
next prev parent reply other threads:[~2011-09-24 14:42 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 [this message]
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=4E7DEC4A.3050900@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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