Re: Bug: send-pack does not respect http.signingkey

On Thu, Jul 16, 2015 at 3:08 PM, Dave Borowitz [off-list ref] wrote:

On Thu, Jul 16, 2015 at 2:10 PM, Junio C Hamano [off-list ref] wrote:

quoted

Dave Borowitz [off-list ref] writes:

quoted

On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano [off-list ref] wrote:

quoted

Dave Borowitz [off-list ref] writes:

quoted

On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano [off-list ref] wrote:

quoted

Perhaps something like this?

Seems like it should work.

Jonathan had suggested there might be some principled reason why
send-pack does not respect config options, and suggested passing it in
as a flag. But that would be more work, certainly, as it would also
have to get passed through git-remote-http somehow.

I actually was wondering about exactly the same thing as Jonathan,
and that is where my "Perhaps" came from.

I will say, though, as the maintainer of a handful of custom remote
helpers, I would prefer a solution that does not involve changing the
implementation of those just to pass this configuration through.

That is not a controversial part ;-)

quoted

So my
vote would be for send-pack to respect the normal config options.

The thing is what should be included in the "normal" config options.

The "something like this?" patch was deliberately narrow, including
only the GPG thing and nothing else.  But anticipating that the ref
backend would be per repo configuration, and send-pack would want to
read from refs (and possibly write back tracking?), we may want to
prepare ourselves by reading a bit wider than "GPG thing and nothing
else", e.g. git_default_config() or something like that.

Ah, now I understand the question. I have no opinion other than that
we shouldn't let discussion about future features prevent us from
fixing this obvious signed push bug :)

Should I formally send a patch with your configuration one-liner?