From: Duy Nguyen <firstname.lastname@example.org> To: Ramkumar Ramachandra <email@example.com> Cc: Jeff King <firstname.lastname@example.org>, Git Mailing List <email@example.com>, Junio C Hamano <firstname.lastname@example.org> Subject: Re: [PATCH 3/4] cat-file: add --batch-disk-sizes option Date: Mon, 8 Jul 2013 20:13:18 +0700 [thread overview] Message-ID: <CACsJy8Dffc2WgtDyUS2g2gmDWG_rTxs389fHcj0ztm6pdJddjQ@mail.gmail.com> (raw) In-Reply-To: <CALkWK0ktNK49zBM4tD8fpNN3VMan7DegfWRtDcOEgTyEbSK9Uw@mail.gmail.com> On Mon, Jul 8, 2013 at 7:00 PM, Ramkumar Ramachandra <email@example.com> wrote: >> This is what I wanted to do with the in for-each-ref's pretty >> formatting . I used to hack cat-file --batch to extract info I >> needed for experimenting with various pack index extensions. If you >> are not in hurry, maybe we can introduce something similar to your >> syntax, but applicable for all for-each-ref, branch and log family. > > I'm still quite confused about this "grand plan". We have short > commit-specific format specifiers that don't work with refs, among > several other quirks in . I personally think we should absolutely > stay away from short format-specifiers (like %H, %f, %e; we'll soon > run out of letters, and nobody can tell what they are without the > documentation anyway) for the new options, and just start adding new > long-form ones as and when they are necessary. I think refname:short, > upstream:track, upstream:trackshort are very sensible choices, and > that we should continue along that line. I'm fine with > format-specifiers having meanings only in certain contexts as long as > we document it properly (how can we possibly get %(refname) to mean > something sensible in cat-file?). The short/long naming is the least I worry about. We could add long names to pretty specifiers. The thing about the last attempt is, you add some extra things on top elsewhere, but format_commit_item code may need to be aware of those changes, which are not obvious when sombody just focuses on format_commit_item. Having all specifiers in one place would be better (hence no hooks, no callbacks) because we get a full picture. And yes we need to deal with specifers that make no sense in certain context. All that makes changes bigger, but when format_commit_item (now just "format_item") knows how to deal with all kinds of objects and refs, it becomes a small declaration language to extract things out of git. You can use it for pretty printing or mass extraction in the case of "cat-file --batch". "cat-file --batch" is just some bonus on top, mostly to exercise that we do it right. > As far as this series is concerned, I think Peff can implement %H and > %(object:[disk-]size) locally without worrying about code-sharing or > waiting for us. Then, after the for-each-ref-pretty thing matures, we > can just replace the code underneath. There's also syntax sharing. I don't think each command should have its own syntax. f-e-r already has %(objectsize). If we plan to have a common syntax, perhaps %(disk-size) should be %(objectsize:disk) or something. Adding formatting to cat-file --batch from scratch could be another big chunk of code (that also comes with bugs, usually) and may or may not be compatible with the common syntax because of some oversight. --batch-cols=... or --batch-disk-size would be simpler, but we might never be able to remove that code. -- Duy
next prev parent reply other threads:[~2013-07-08 13:13 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-07 10:01 [RFC/PATCH 0/4] cat-file --batch-disk-sizes Jeff King 2013-07-07 10:03 ` [PATCH 1/4] zero-initialize object_info structs Jeff King 2013-07-07 17:34 ` Junio C Hamano 2013-07-07 10:04 ` [PATCH 2/4] teach sha1_object_info_extended a "disk_size" query Jeff King 2013-07-07 10:09 ` [PATCH 3/4] cat-file: add --batch-disk-sizes option Jeff King 2013-07-07 17:49 ` Junio C Hamano 2013-07-07 18:19 ` Jeff King 2013-07-08 11:04 ` Duy Nguyen 2013-07-08 12:00 ` Ramkumar Ramachandra 2013-07-08 13:13 ` Duy Nguyen [this message] 2013-07-08 13:37 ` Ramkumar Ramachandra 2013-07-09 2:55 ` Duy Nguyen 2013-07-09 10:32 ` Ramkumar Ramachandra 2013-07-10 11:16 ` Jeff King 2013-07-08 16:40 ` Junio C Hamano 2013-07-10 11:04 ` Jeff King 2013-07-11 16:35 ` Junio C Hamano 2013-07-07 21:15 ` brian m. carlson 2013-07-10 10:57 ` Jeff King 2013-07-07 10:14 ` [PATCH 4/4] pack-revindex: radix-sort the revindex Jeff King 2013-07-07 23:52 ` Shawn Pearce 2013-07-08 7:57 ` Jeff King 2013-07-08 15:38 ` Shawn Pearce 2013-07-08 20:50 ` Brandon Casey 2013-07-08 21:35 ` Brandon Casey 2013-07-10 10:57 ` Jeff King 2013-07-10 10:52 ` Jeff King 2013-07-10 11:34 ` [PATCHv2 00/10] cat-file formats/on-disk sizes Jeff King 2013-07-10 11:35 ` [PATCH 01/10] zero-initialize object_info structs Jeff King 2013-07-10 11:35 ` [PATCH 02/10] teach sha1_object_info_extended a "disk_size" query Jeff King 2013-07-10 11:36 ` [PATCH 03/10] t1006: modernize output comparisons Jeff King 2013-07-10 11:38 ` [PATCH 04/10] cat-file: teach --batch to stream blob objects Jeff King 2013-07-10 11:38 ` [PATCH 05/10] cat-file: refactor --batch option parsing Jeff King 2013-07-10 11:45 ` [PATCH 06/10] cat-file: add --batch-check=<format> Jeff King 2013-07-10 11:57 ` Eric Sunshine 2013-07-10 14:51 ` Ramkumar Ramachandra 2013-07-11 11:24 ` Jeff King 2013-07-10 11:46 ` [PATCH 07/10] cat-file: add %(objectsize:disk) format atom Jeff King 2013-07-10 11:48 ` [PATCH 08/10] cat-file: split --batch input lines on whitespace Jeff King 2013-07-10 15:29 ` Ramkumar Ramachandra 2013-07-11 11:36 ` Jeff King 2013-07-11 17:42 ` Junio C Hamano 2013-07-11 20:45 ` [PATCHv3 " Jeff King 2013-07-10 11:50 ` [PATCH 09/10] pack-revindex: use unsigned to store number of objects Jeff King 2013-07-10 11:55 ` [PATCH 10/10] pack-revindex: radix-sort the revindex Jeff King 2013-07-10 12:00 ` Jeff King 2013-07-10 13:17 ` Ramkumar Ramachandra 2013-07-11 11:03 ` Jeff King 2013-07-10 17:10 ` Brandon Casey 2013-07-11 11:17 ` Jeff King 2013-07-11 12:16 ` [PATCHv3 " Jeff King 2013-07-11 21:12 ` Brandon Casey
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 List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CACsJy8Dffc2WgtDyUS2g2gmDWG_rTxs389fHcj0ztm6pdJddjQ@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 3/4] cat-file: add --batch-disk-sizes option' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git 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 read-only IMAP folder(s) and NNTP newsgroup(s).