public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 6/6] sha1_name: implement @{push} shorthand
Date: Tue, 31 Mar 2015 14:37:25 -0700	[thread overview]
Message-ID: <xmqqk2xwq25m.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150331173834.GF18912@peff.net> (Jeff King's message of "Tue, 31 Mar 2015 13:38:35 -0400")

Jeff King <peff@peff•net> writes:

> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
> index 0796118..5d9df25 100644
> --- a/Documentation/revisions.txt
> +++ b/Documentation/revisions.txt
> @@ -98,6 +98,31 @@ some output processing may assume ref names in UTF-8.
>    `branch.<name>.merge`).  A missing branchname defaults to the
>    current one.
>  
> +'<branchname>@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
> +  The suffix `@{push}` reports the branch "where we would push to" if

The corresponding description for upstream begins like this:

  The suffix '@\{upstream\}' to a branchname (short form '<branchname>@\{u\}')

and makes me wonder if the existing backslashes are unnecessary, or
if you forgot to use them in the new text.

> @@ -1104,6 +1111,95 @@ static int interpret_upstream_mark(const char *name, int namelen,
>  	return len + at;
>  }
>  
> +static char *tracking_ref_for(struct remote *remote, const char *refname)
> +{
> +	char *ret;
> +
> +	ret = apply_refspecs(remote->fetch, remote->fetch_refspec_nr, refname);
> +	if (!ret)
> +		die(_("@{push} has no local tracking branch for remote '%s'"),
> +		    refname);

I would imagine that it would be very plausible that anybody with a
specific remote and the name of the ref that appears on that remote
would want to learn the local name of the remote-tracking ref we use
to track it.

But the error message limits the callers only to those who are
involved in @{push} codepath.  Shouldn't the error check be done in
the caller instead, anticipating the day this useful function ceases
to be static?

I would suspect that such a change would make it just a one-liner,
but I think this helper that takes remote and their refname is much
easier to read than four inlined calls to apply_refspecs() that have
to spell out remote->fetch, remote->fetch_refspec_nr separately.

Perhaps we would want 

	struct refspecs {
        	int nr, alloc;
                const char **refspec;
	} fetch_refspec;

in "struct remote", instead of these two separate fields, and then
make apply_refspecs() take "struct refspecs *"?  I haven't checked
and thought enough to decide if we want "struct refspec *" also in
that new struct, though.

  reply	other threads:[~2015-03-31 21:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-31 17:33 [PATCH 0/6] implement @{push} shorthand Jeff King
2015-03-31 17:34 ` [PATCH 1/6] remote.c: drop default_remote_name variable Jeff King
2015-03-31 20:37   ` Junio C Hamano
2015-03-31 22:22     ` Jeff King
2015-03-31 17:35 ` [PATCH 2/6] remote.c: drop "remote" pointer from "struct branch" Jeff King
2015-03-31 20:50   ` Junio C Hamano
2015-03-31 22:24     ` Jeff King
2015-03-31 22:29       ` Junio C Hamano
2015-03-31 17:36 ` [PATCH 3/6] remote.c: hoist branch.*.remote lookup out of remote_get_1 Jeff King
2015-03-31 17:37 ` [PATCH 4/6] remote.c: provide per-branch pushremote name Jeff King
2015-03-31 21:41   ` Junio C Hamano
2015-03-31 17:37 ` [PATCH 5/6] sha1_name: refactor upstream_mark Jeff King
2015-03-31 17:38 ` [PATCH 6/6] sha1_name: implement @{push} shorthand Jeff King
2015-03-31 21:37   ` Junio C Hamano [this message]
2015-03-31 22:32     ` Jeff King
2015-03-31 22:57       ` Junio C Hamano
2015-03-31 21:41   ` Eric Sunshine
2015-03-31 22:33     ` 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=xmqqk2xwq25m.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=peff@peff$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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