git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: "Karthik Nayak" <karthik.188@gmail.com>,
	"Git mailing list" <git@vger.kernel.org>,
	"Jakub Narębski" <jnareb@gmail.com>
Subject: Re: [PATCH v8 00/19] port branch.c to use ref-filter's printing options
Date: Thu, 08 Dec 2016 10:58:39 -0800	[thread overview]
Message-ID: <xmqqa8c6tfhc.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CA+P7+xquordVY19dypqNcAuQqoRbFmHhzb0w+HXCaJmm_Ex7zQ@mail.gmail.com> (Jacob Keller's message of "Wed, 7 Dec 2016 16:01:48 -0800")

Jacob Keller <jacob.keller@gmail.com> writes:

>> +       are left behind.  If a displayed ref has fewer components than
>> +       `<N>`, the command aborts with an error.
>>
>
> Would it make more sense to not die and instead just return the empty
> string? On the one hand, if we die() it's obvious that you tried to
> strip too many components. But on the other hand, it's also somewhat
> annoying to have the whole command fail because we happen upon a
> single ref that has fewer components?
>
> So, for positive numbers, we simply strip what we can, which may
> result in the empty string, and for negative numbers, we keep up to
> what we said, while potentially keeping the entire string. I feel
> that's a better alternative than a die() in the middle of a ref
> filter..
>
> What are other people's thoughts on this?

There probably are three ways to handle a formatting request that
cannot be satisfied for some refs but not others [*1*].  I agree
with you that dying the whole thing is probably the least useful
one.

We already format "%(taggername)" into an empty string when the ref
points at an object that is not an annotated tag, and substituting
an unsatisifiable request "%(refname:lstrip=N)" with an empty string
for a ref whose name does not have enough number of components is in
line with that existing practice.

The other possibility is to omit refs that cannot be formatted
according to the format specifier.  We do not currently have
provision for doing so, but it may not be bad if we can say:

    $ git for-each-ref \
	--require="%(taggername)" \
	--require="%(refname:lstrip=4)" \
	--format="%(refname:short)" \
	refs/tags/

to list _only_ annotated tags that has at least 4 components from
refs/tags/ hierarchy.

The "--require" thing obviously is an orthogonal feature, that
nobody has asked for, and does not have to exist.  For the purpose
of this review thread, I think it is OK to just conclude:

    "--format" should replace "%(any unsatisifiable atom)" with an
    empty string.

Thanks.

[Footnote]

*1* A malformed formatting request (e.g. %(if) that is not closed)
    cannot be satisified but that is true for all refs and is
    outside of the scope of this discussion.  The command should die
    and I think it already does.

  reply	other threads:[~2016-12-08 18:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-07 15:36 [PATCH v8 00/19] port branch.c to use ref-filter's printing options Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 01/19] ref-filter: implement %(if), %(then), and %(else) atoms Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 02/19] ref-filter: include reference to 'used_atom' within 'atom_value' Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 03/19] ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>) Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 04/19] ref-filter: modify "%(objectname:short)" to take length Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 05/19] ref-filter: move get_head_description() from branch.c Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 06/19] ref-filter: introduce format_ref_array_item() Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 07/19] ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 08/19] ref-filter: add support for %(upstream:track,nobracket) Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 09/19] ref-filter: make "%(symref)" atom work with the ':short' modifier Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 10/19] ref-filter: introduce refname_atom_parser_internal() Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 11/19] ref-filter: introduce refname_atom_parser() Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 12/19] ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal() Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 13/19] ref-filter: rename the 'strip' option to 'lstrip' Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 14/19] ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>' Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 15/19] ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 16/19] ref-filter: allow porcelain to translate messages in the output Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 17/19] branch, tag: use porcelain output Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 18/19] branch: use ref-filter printing APIs Karthik Nayak
2016-12-09 14:03   ` Jeff King
2016-12-12 11:20     ` Karthik Nayak
2016-12-12 12:15       ` Jeff King
2016-12-12 16:29         ` Karthik Nayak
2016-12-12 16:40           ` Jeff King
2016-12-12 17:18             ` Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 19/19] branch: implement '--format' option Karthik Nayak
2016-12-08  0:01 ` [PATCH v8 00/19] port branch.c to use ref-filter's printing options Jacob Keller
2016-12-08 18:58   ` Junio C Hamano [this message]
2016-12-09  1:45     ` Jacob Keller
2016-12-12 10:42   ` Karthik Nayak
2016-12-08 23:58 ` Junio C Hamano
2016-12-12 10:43   ` Karthik Nayak

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=xmqqa8c6tfhc.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.keller@gmail.com \
    --cc=jnareb@gmail.com \
    --cc=karthik.188@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.
Code repositories for project(s) associated with this public 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).