From: Jeff King <peff@peff.net>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 04/12] remote.c: provide per-branch pushremote name
Date: Tue, 5 May 2015 15:33:39 -0400 [thread overview]
Message-ID: <20150505193339.GF10463@peff.net> (raw)
In-Reply-To: <CAPig+cT7pSxZahd1hmcwCW8ifZfvQ4YW6L7xXUrD7dTJt76srQ@mail.gmail.com>
On Sun, May 03, 2015 at 12:51:13AM -0400, Eric Sunshine wrote:
> > Versus v1, I did something a little clever by passing a function pointer
> > around (versus a flag and letting the caller do a conditional based on
> > the flag). Too clever?
>
> FWIW: I found this "clever" version easy enough to follow.
>
> However, if you push a tiny bit of the work into the callers of
> remote_get_1(), then you can do away with the "cleverness" altogether,
> can't you? Something like this:
Yeah, it's just that it goes in the opposite direction I was trying for,
which is to have as little code as possible in the wrapper functions (in
fact, I think after my changes you could even bump the read_config()
call into remote_get_1; before my changes, it depended on the pushremote
config being set before the call).
I agree it is not so much code, though, and maybe it makes the flow a
little clearer. I'll play with it for the re-roll.
-Peff
next prev parent reply other threads:[~2015-05-05 19:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-01 22:44 [PATCH v2 0/12] implement @{push} shorthand Jeff King
2015-05-01 22:44 ` [PATCH 01/12] remote.c: drop default_remote_name variable Jeff King
2015-05-01 22:45 ` [PATCH 02/12] remote.c: drop "remote" pointer from "struct branch" Jeff King
2015-05-03 3:34 ` Eric Sunshine
2015-05-05 19:31 ` Jeff King
2015-05-07 9:33 ` Jeff King
2015-05-01 22:45 ` [PATCH 03/12] remote.c: hoist branch.*.remote lookup out of remote_get_1 Jeff King
2015-05-01 22:46 ` [PATCH 04/12] remote.c: provide per-branch pushremote name Jeff King
2015-05-03 4:51 ` Eric Sunshine
2015-05-05 19:33 ` Jeff King [this message]
2015-05-05 19:48 ` Eric Sunshine
2015-05-07 9:38 ` Jeff King
2015-05-08 16:13 ` Eric Sunshine
2015-05-01 22:47 ` [PATCH 05/12] remote.c: introduce branch_get_upstream helper Jeff King
2015-05-01 22:52 ` [PATCH 06/12] remote.c: report specific errors from branch_get_upstream Jeff King
2015-05-01 22:53 ` [PATCH 07/12] remote.c: add branch_get_push Jeff King
2015-05-01 22:53 ` [PATCH 08/12] sha1_name: refactor upstream_mark Jeff King
2015-05-01 22:55 ` [PATCH 09/12] sha1_name: refactor interpret_upstream_mark Jeff King
2015-05-01 22:55 ` [PATCH 10/12] sha1_name: implement @{push} shorthand Jeff King
2015-05-01 22:55 ` [PATCH 11/12] for-each-ref: use skip_prefix instead of starts_with Jeff King
2015-05-01 22:56 ` [PATCH 12/12] for-each-ref: accept "%(push)" format 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=20150505193339.GF10463@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=sunshine@sunshineco.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.