Thread (4 messages) flat view 4 messages, 4 authors, 2016-06-15

Re: [PATCH 1/4] Refactoring: remove duplicated code from transport.c and builtin-send-pack.c

From: Daniel Barkalow <hidden>
Date: 2016-06-15 22:48:17

On Mon, 15 Feb 2010, Jeff King wrote:
On Sun, Feb 14, 2010 at 10:34:20PM -0800, Junio C Hamano wrote:
quoted
quoted
I can't remember the exact details of why the originals were not
removed, though (I think I complained about it once before, and there
was some technical reason, but I don't recall now). Daniel (cc'd) might
remember more.
Also the names of these functions probably need to be made more specific
so that people not so familiar with the transport code can tell that they
are from "transport" family.  The names didn't matter much while they were
file scope static, but this series changes that.
Actually, I wonder if we can simply get rid of some of the calls in
send-pack. I think that the code in send-pack isn't even called anymore
via "git push"; it only gets called when you call send-pack directly.
And arguably send-pack as plumbing shouldn't be generating all sorts of
user-facing output. But it is a behavior change. I wonder if anybody
actually calls send-pack directly anymore. It seems like even scripts
use "git push" because of the transport agnosticism.
I think it would probably be better to get rid of send-pack as a separate 
command entirely, rather than changing any of its behavior, and make 
remote-curl use a private command that only has the desired behavior, 
which is stdio to a local proxy for the remote.

For that matter, it would likely be worthwhile abstracting the packet_line 
code such that send-pack (and fetch-pack) could be done in-process without 
the messages going over a classic packet_line connection to remote-curl 
before being sent over HTTP to the actual server.

	-Daniel
*This .sig left intentionally blank*
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help