Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 2, 2009, 18:07 UTC
- Message-ID
- <7vskbtfdvo.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <alpine.DEB.1.00.0912021832480.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 7 quoted lines
> This is definitely a good direction, and it would be even better if the > absence of the remote helper was also handled gracefully. Just think > about a (as of now fictious) git-remote-http.rpm relying on git-core.rpm > and libcurl.rpm. If you do not want to access http:// URLs, you can > install just git-core. Once you encounter an http:// URL you need to > access, you install git-remote-http. Keeping git-core. (I like to call > this setup "modular".)
The "modular" setup is a good thing to do, but I do not know how it relates to the change Ilari did. Isn't it simply a matter of excluding git-remote-curl from the current set of binaries to be shipped with git-core.rpm and making a separate git-remote-http.rpm to contain it, or does it involve a lot more than that from the packager's side?