Re: What's cooking in git.git (Apr 2015, #04; Mon, 27)

From: Jeff King <peff@peff.net>
Date: Apr 30, 2015, 01:02 UTC
Message-ID: <20150430010256.GA5089@peff.net>
In-Reply-To: <xmqqbni64kum.fsf@gitster.dls.corp.google.com>

On Wed, Apr 29, 2015 at 03:42:57PM -0700, Junio C Hamano wrote:

Show 13 quoted lines

> > * jk/at-push-sha1 (2015-03-31) 6 commits
> >  - sha1_name: implement @{push} shorthand
> >  - sha1_name: refactor upstream_mark
> >  - remote.c: provide per-branch pushremote name
> >  - remote.c: hoist branch.*.remote lookup out of remote_get_1
> >  - remote.c: drop "remote" pointer from "struct branch"
> >  - remote.c: drop default_remote_name variable
> >
> >  Introduce <branch>@{push} short-hand to denote the remote-tracking
> >  branch that tracks the branch at the remote the <branch> would be
> >  pushed to.
> >
> >  Waiting for a reroll ($gmane/266573).

I re-rolled this and _almost_ sent it out last week. But I noticed that it gives us only "git rev-parse foo@{push}" and not "git for-each-ref --format=%(push)" (whereas we have "upstream" for both versions). For "upstream", computing the answer is simple enough that the tiny bit of logic is largely duplicated in the two spots. For @{push}, that would be a bad idea. So I started refactoring the final patch to use the same logic in both spots, but didn't finish.

I can send the intermediate version (i.e., the re-roll with a few minor fixups based on list comments), and we can build the other on top, but I don't think there's any rush, and it can wait for the refactor (which shouldn't be _too_ bad, I don't think).

-Peff