Re: [PATCH 1/4] Refactoring: remove duplicated code from transport.c and builtin-send-pack.c
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Feb 15, 2010, 18:25 UTC
- Message-ID
- <alpine.LNX.2.00.1002151250030.14365@iabervon.org>
- In-Reply-To
- <20100215075514.GB5347@coredump.intra.peff.net>
On Mon, 15 Feb 2010, Jeff King wrote:
Show 19 quoted lines
> On Sun, Feb 14, 2010 at 10:34:20PM -0800, Junio C Hamano wrote: > > > > 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*