git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <johannes.schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/3] for-each-ref: let upstream/push optionally report the remote name
Date: Wed, 04 Oct 2017 16:14:07 +0900
Message-ID: <xmqq376zcrls.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <0e03bf1e50e24a52f57be0f51d19f4657c68d2fa.1506952571.git.johannes.schindelin@gmx.de>

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> This patch offers the new suffix :remote for the upstream and for the
> push atoms, allowing to show exactly that.

Has the design changed since this description and examples were
written?  The documentation talks about ":remote-name".  I suspect
calling this ":remote" might be less hassle, as we do not have to
vet the current vocabulary to see if "remote-name" is the right way
to name a multi-word modifer (as opposed to "remotename", or
"remoteName", or "remote_name", or...).

> 	...
>
> 	$ git for-each-ref \
> 		--format='%(upstream) %(upstream:remote) %(push:remote)' \
> 		refs/heads/master

> diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
> index 66b4e0a4050..776368ee531 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -140,17 +140,19 @@ upstream::

Aside from "':remote-name'?  Do we really want that?" issue I
already mentioned, the changes to this file look sensible.

> diff --git a/ref-filter.c b/ref-filter.c
> index bc591f4f3de..58d53c09390 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -76,7 +76,9 @@ static struct used_atom {
>  		char color[COLOR_MAXLEN];
>  		struct align align;
>  		struct {
> -			enum { RR_REF, RR_TRACK, RR_TRACKSHORT } option;
> +			enum {
> +				RR_REF, RR_TRACK, RR_TRACKSHORT, RR_REMOTE_NAME
> +			} option;
>  			struct refname_atom refname;
>  			unsigned int nobracket : 1;
>  		} remote_ref;
> @@ -156,6 +158,8 @@ static void remote_ref_atom_parser(const struct ref_format *format, struct used_
>  			atom->u.remote_ref.option = RR_TRACKSHORT;
>  		else if (!strcmp(s, "nobracket"))
>  			atom->u.remote_ref.nobracket = 1;
> +		else if (!strcmp(s, "remote-name"))
> +			atom->u.remote_ref.option = RR_REMOTE_NAME;
>  		else {
>  			atom->u.remote_ref.option = RR_REF;
>  			refname_atom_parser_internal(&atom->u.remote_ref.refname,
> @@ -1247,6 +1251,15 @@ static void fill_remote_ref_details(struct used_atom *atom, const char *refname,
>  			*s = ">";
>  		else
>  			*s = "<>";
> +	} else if (atom->u.remote_ref.option == RR_REMOTE_NAME) {
> +		int explicit;
> +		const char *remote = starts_with(atom->name, "push") ?
> +			pushremote_for_branch(branch, &explicit) :
> +			remote_for_branch(branch, &explicit);

I think "int explicit = 0;" is needed, as pushremote_for_branch()
does seem to expect that the "explicit" return parameter is
initialized by the caller.

> +		if (explicit)
> +			*s = xstrdup(remote);
> +		else
> +			*s = "";

This one is debatable.  For the user of "push" who wants to learn
where the branch is pushed to, the choice this patch makes is not
useful (i.e. such a user does not care where the definition comes
from; s/he only wants to know where the push goes).  For the user of
"git config" who wants to know how pushremote is configured, and
does not want to accept the fallback to remote, the behaviour of
this patch is useful.  I have a mild suspicion that majority of
users who would want to use this feature would fall into the former
category, i.e. users of "push", rather than the latter, i.e.
debuggers of their config files, and if that is true, we can drop
the whole "explicit" business to simplify the code and get a more
useful behaviour at the same time ;-)

> @@ -1364,9 +1377,13 @@ static void populate_value(struct ref_array_item *ref)
>  				continue;
>  			branch = branch_get(branch_name);
>  
> -			refname = branch_get_push(branch, NULL);
> -			if (!refname)
> -				continue;
> +			if (starts_with(name, "push:remote-"))

I am not sure what is going on here.  

Are we expecting "push:remote-name" here, or anticipating
"push:remote-bar" can also be given or what?

> +				refname = NULL;
> +			else {
> +				refname = branch_get_push(branch, NULL);
> +				if (!refname)
> +					continue;
> +			}
>  			fill_remote_ref_details(atom, refname, branch, &v->s);
>  			continue;
>  		} else if (starts_with(name, "color:")) {

  reply index

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-02 13:56 [PATCH 0/3] for-each-ref: add :remote-ref and :remote-name specifiers Johannes Schindelin
2017-10-02 13:56 ` [PATCH 1/3] for-each-ref: let upstream/push optionally report the remote name Johannes Schindelin
2017-10-04  7:14   ` Junio C Hamano [this message]
2017-10-04  9:08     ` Junio C Hamano
2017-10-05 12:20     ` Johannes Schindelin
2017-10-02 13:57 ` [PATCH 2/3] for-each-ref: let upstream/push optionally report merge name Johannes Schindelin
2017-10-04  9:12   ` Junio C Hamano
2017-10-04 11:41     ` Junio C Hamano
2017-10-05  9:14       ` Junio C Hamano
2017-10-02 13:57 ` [PATCH 3/3] for-each-ref: test :remote-name and :remote-ref Johannes Schindelin
2017-10-05  1:54 ` [PATCH 0/3] for-each-ref: add :remote-ref and :remote-name specifiers Junio C Hamano
2017-10-05 12:19 ` [PATCH v2 0/3] for-each-ref: add :remoteref and :remotename specifiers Johannes Schindelin
2017-10-05 12:19   ` [PATCH v2 1/3] for-each-ref: let upstream/push optionally report the remote name Johannes Schindelin
2017-10-10  9:35     ` Junio C Hamano
2017-10-11  2:07     ` Junio C Hamano
2017-10-05 12:19   ` [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote ref name Johannes Schindelin
2017-10-06  5:10     ` Junio C Hamano
2017-10-11  5:58       ` Junio C Hamano
2017-10-12 19:13         ` Johannes Schindelin
2017-10-13  0:30           ` Junio C Hamano
2017-10-15 16:02             ` Johannes Schindelin
2017-10-13 16:39     ` Kevin Daudt
2017-10-14  2:08       ` Junio C Hamano
2017-10-15 16:05         ` Johannes Schindelin
2017-10-16  1:50           ` Junio C Hamano
2017-10-16 11:39             ` Johannes Schindelin
2017-10-05 12:19   ` [PATCH v2 3/3] for-each-ref: test :remotename and :remoteref Johannes Schindelin
2017-11-07 16:30   ` [PATCH v3 0/3] for-each-ref: add :remoteref and :remotename specifiers Johannes Schindelin
2017-11-07 16:30     ` [PATCH v3 1/3] for-each-ref: let upstream/push optionally report the remote name Johannes Schindelin
2017-11-07 16:31     ` [PATCH v3 2/3] for-each-ref: let upstream/push report the remote ref name Johannes Schindelin
2017-11-07 16:31     ` [PATCH v3 3/3] for-each-ref: test :remotename and :remoteref Johannes Schindelin
2017-11-08  1:36     ` [PATCH v3 0/3] for-each-ref: add :remoteref and :remotename specifiers Junio C Hamano

Reply instructions:

You may reply publically 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=xmqq376zcrls.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    /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

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox