From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jukka Lehtniemi <jukka.lehtniemi@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH v2] Fix notes handling in rev-list
Date: Thu, 19 Jul 2012 07:35:35 -0400 [thread overview]
Message-ID: <20120719113535.GA29774@sigill.intra.peff.net> (raw)
In-Reply-To: <7vhat4wv6h.fsf@alter.siamese.dyndns.org>
On Wed, Jul 18, 2012 at 03:39:34PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > So leaving aside the --graph issues, we would need to decide what to
> > show in the non-graph case. And I think your suggestion is good; there
> > is no real need to dereference the blob (if you want that, you can turn
> > on the pretty-printer).
> >
> > I'm just not sure what the output should be. I guess:
> >
> > <commit_sha1> <notes sha1s>
> >
> > is probably the most sensible (it's sort of like --parents). And that
> > solves the --graph issue, too, since it continues to take only a single
> > line.
>
> Surely. "rev-list --parents --notes" would still be usable that
> way, as a reader that requests such a combination is prepared to
> tell commits (i.e. parents) and blobs (i.e. notes) apart.
I don't think we forbid non-blob values in notes trees, so technically
there could be some ambiguity. I doubt it is a big problem in practice
(especially since I haven't even heard of a good use case yet for "git
rev-list --notes", let alone "git rev-list --notes --parents"). But now
would be the time to avoid a crappy format that we will be stuck with
later.
Unlike elements of the commit object itself, like --parents or
--timestamp, notes do not really gain any efficiency by being printed as
part of the traversal. So modulo the cost of piping the list of commits,
it would not really be any more efficient than "git rev-list | git notes
list --stdin" (except that the latter does not take a --stdin argument,
but could easily do so). And the latter is way more flexible.
So for plumbing, I think this is the wrong direction, anyway. The real
value of this patch is that the pretty-printed code path would work more
like git-log (especially the "%N" format, which lets callers make their
own micro-format for specifying all the bits they are interested in).
Maybe the best thing is to simply disallow --notes when not using a
pretty-printed format.
-Peff
next prev parent reply other threads:[~2012-07-19 11:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-24 19:38 [PATCH] rev-list: fix place holder %N (notes) in user format Jukka Lehtniemi
2012-03-25 0:55 ` Jeff King
2012-07-16 18:30 ` [PATCH v2] Fix notes handling in rev-list Jukka Lehtniemi
2012-07-16 19:03 ` Junio C Hamano
2012-07-17 3:17 ` Jeff King
2012-07-17 3:40 ` Junio C Hamano
2012-07-17 3:51 ` Jeff King
2012-07-17 3:46 ` Jeff King
2012-07-17 5:42 ` Junio C Hamano
2012-07-17 21:22 ` Jukka Lehtniemi
2012-07-18 7:21 ` Jeff King
2012-07-18 22:39 ` Junio C Hamano
2012-07-19 11:35 ` Jeff King [this message]
2012-07-19 17:20 ` Junio C Hamano
2012-07-19 17:25 ` Jeff King
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=20120719113535.GA29774@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jukka.lehtniemi@gmail.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).