All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Rafael Ascensão" <rafa.almas@gmail.com>
Cc: Jacob Keller <jacob.keller@gmail.com>,
	git@vger.kernel.org, me@ikke.info, hjemli@gmail.com,
	mhagger@alum.mit.edu, pclouds@gmail.com,
	ilari.liusvaara@elisanet.fi
Subject: Re: [PATCH v1 2/2] log: add option to choose which refs to decorate
Date: Sat, 11 Nov 2017 02:42:43 +0900	[thread overview]
Message-ID: <xmqqo9oaf2ss.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <89e7f8e0-8b0d-fde0-5e28-31173213a26e@gmail.com> ("Rafael =?utf-8?Q?Ascens=C3=A3o=22's?= message of "Fri, 10 Nov 2017 13:38:48 +0000")

Rafael Ascensão <rafa.almas@gmail.com> writes:

> I agree that describe should receive the "normalize" treatment. However,
> and following the same reasoning, why should describe users adopt the
> rules imposed by --glob? I could argue they're also used to the way it
> works now.
>
> That being said, the suggestion I mentioned earlier would allow to keep
> both current behaviors consistent at the expense of the extra call to
> refs.c::ref_exists().

In any case, updating the "describe" for consistency is something we
can and should leave for later, to be done as a separate topic.

While I agree with you that the consistent behaviour between
commands is desirable, and also I agree with you that given a
pattern $X that does not have any glob char, trying to match $X when
a ref whose name exactly is $X exists and trying to match $X/*
otherwise would give us a consistent semantics without hurting any
existing uses, I do not think you need to pay any extra expense of
calling ref_exists() at all to achieve that.

That is because when $X exists, you already know $X/otherthing does
not exist.  And when $X does not exist, $X/otherthing might.  So a
naive implementation would be just to add two patterns $X and $X/*
to the filter list and be done with it.  If you exactly have
refs/heads/master, even with the naive logic may throw both
refs/heads/master and refs/heads/master/* to the filter list,
nothing will match the latter to contaminate your result (and vice
versa).

A bit more clever implementation "just throw in two items" would go
like this.  It is not all that involved:

 - In load_ref_decorations(), before running add_ref_decoration for
   each ref and head ref, iterate over the elements in the refname
   filter list.  For each element:

   - if item->string has a trailing '/', trim that.

   - store NULL in the item->util field for item whose string field
     has a glob char.

   - store something non-NULL (e.g. item->string) for item whose
     string field does not have a glob char.

 - In add_ref_decoration(), where your previous round iterates over
   filter->{include,exclude}, get rid of normalize_glob_ref() and
   use of real_pattern.  Instead do something like:

	matched = 0;
	if (item->util == NULL) {
		if (!wildmatch(item->string, refname, 0))
                	matched = 1;
	} else {
		const char *rest;
		if (skip_prefix(refname, item->string, &rest) &&
                    (!*rest || *rest == '/'))
			matched = 1;
	}
	if (matched)
		...

   Of course, you would probably want to encapsulate the logic to
   set matched = 1/0 in a helper function, e.g.

	static int match_ref_pattern(const char *refname,
				     const struct string_list_item *item) {
		int matched = 0;
		... do either wildmatch or head match with tail validation
		... depending on the item->util's NULLness (see above)
		return matched;
	}

   and call that from the two loops for exclude and include list.

Hmm?

  reply	other threads:[~2017-11-10 17:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-04  0:41 [PATCH v1 0/2] Add option to git log to choose which refs receive decoration Rafael Ascensão
2017-11-04  0:41 ` [PATCH v1 1/2] refs: extract function to normalize partial refs Rafael Ascensão
2017-11-04  2:27   ` Junio C Hamano
2017-11-04  7:33     ` Rafael Ascensão
2017-11-04 22:45     ` Kevin Daudt
2017-11-05 13:21       ` Michael Haggerty
2017-11-05 13:42   ` Michael Haggerty
2017-11-06  1:23     ` Junio C Hamano
2017-11-06  2:37       ` Rafael Ascensão
2017-11-06  7:00       ` Michael Haggerty
2017-11-04  0:41 ` [PATCH v1 2/2] log: add option to choose which refs to decorate Rafael Ascensão
2017-11-04  3:49   ` Junio C Hamano
2017-11-04  7:34     ` Rafael Ascensão
2017-11-05  2:00       ` Junio C Hamano
2017-11-05  6:17         ` Junio C Hamano
2017-11-06  3:24           ` Rafael Ascensão
2017-11-06  3:51             ` Junio C Hamano
2017-11-06  7:09           ` Michael Haggerty
2017-11-06 20:10     ` Jacob Keller
2017-11-07  0:18       ` Junio C Hamano
2017-11-10 13:38         ` Rafael Ascensão
2017-11-10 17:42           ` Junio C Hamano [this message]
2017-11-21 21:33 ` [PATCH v2] " Rafael Ascensão
2017-11-22  4:18   ` Junio C Hamano

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=xmqqo9oaf2ss.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=hjemli@gmail.com \
    --cc=ilari.liusvaara@elisanet.fi \
    --cc=jacob.keller@gmail.com \
    --cc=me@ikke.info \
    --cc=mhagger@alum.mit.edu \
    --cc=pclouds@gmail.com \
    --cc=rafa.almas@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.