git smart http for busybox repo

[Bernhard Reutner-Fischer]

On 21 April 2020 14:14:50 CEST, Yannik Sembritzki <yannik at sembritzki.me> wrote:
>I'm glad my message ended the unncessary github discussion.
>
>However, I'd still like to know who is in charge of maintaining
>git.busybox.net, so I can forward this suggestion to the right person.

We are doing this as time permits. I have no spare time ATM though.
Thanks for the suggestion, I've put it on the list.
>
>On 14.04.20 09:59, Yannik Sembritzki wrote:
>> Hi everyone,
>>
>> I did not mean to start a discussion about switching to github,
>gitlab
>> or anything similar.
>>
>> This is simply a request for a (small) improvement of the current
>> infrastructure. Eli Schwartz has patiently explained the benefits
>> in-depth. Thank you for this, Eli!
>> As far as I know, there are no downsides to doing this, and it does
>> not change existing workflows.
>>
>> As I do not know who maintains git.busybox.net, I sent this request
>to
>> the busybox mailinglist. If someone knows who maintains
>> git.busybox.net, I will gladly contact that person directly and spare
>> everyone else on this list :-)
>>
>> Thank you
>> Yannik
>>
>> On 14.04.20 02:35, Eli Schwartz wrote:
>>> On 4/13/20 7:54 PM, Bernd Petrovitsch wrote:
>>>> busybox - and thus the git repo - is small.
>>>> What - apart from trolling - motivates "--depth=1"?
>>>> To word it another way: What is a somewhat sane use-case
>>>> for "--depth=1"?
>>> It clones 3 MB instead of 28 MB, which is useful if you don't expect
>to
>>> need history but would still like to submit patches or even directly
>git
>>> push if you have commit access. It's a fairly large difference. It
>saves
>>> bandwidth and decreases the time it takes in order to start working
>>> rather than staring at a blinking cursor waiting to complete.
>>>
>>> It's also able to dynamically grow by using `git fetch --unshallow`
>to
>>> retrieve the rest of the history, so there are no actual downsides
>to
>>> using it when you don't need it.
>>>
>>> But never mind --depth=1, the original post also pointed out that
>modern
>>> revisions of the git-over-http protocol support status messages such
>as:
>>>
>>> remote: Enumerating objects: 110424, done.
>>> remote: Counting objects: 100% (110424/110424), done.
>>> remote: Compressing objects: 100% (28074/28074), done.
>>> remote: Total 110424 (delta 88325), reused 102158 (delta 81649)
>>> Receiving objects: 100% (110424/110424), 27.51 MiB | 4.49 MiB/s,
>done.
>>> Resolving deltas: 100% (88325/88325), done.
>>>
>>> It is also faster even without the depth setting (or rather,
>old-style
>>> git-over-http is just really slow):
>>>
>>> $ time git clone git://git.busybox.net/busybox/ # no TLS validation
>>> [...]
>>> real	0m15.574s
>>> user	0m10.526s
>>> sys	0m0.606s
>>> $ time git clone https://git.busybox.net/busybox/ # with TLS
>validation
>>> [...]
>>> real	2m12.699s
>>> user	0m17.903s
>>> sys	0m4.561s
>>>
>>> There are many good reasons to use modern versions of the wire
>transport
>>> protocol instead of old versions, I'm actually extremely bewildered
>that
>>> this is such a controversial topic.
>>>
>>> It really should not be controversial. It's a very simple,
>pure-benefit
>>> request that simply depends on whether the person in charge of the
>>> server infrastructure has a bit of time to switch it on and
>considers
>>> such to be a useful way to spend that time.
>>>
>>>
>>> _______________________________________________
>>> busybox mailing list
>>> busybox at busybox.net
>>> http://lists.busybox.net/mailman/listinfo/busybox
>>
>>
>>
>> _______________________________________________
>> busybox mailing list
>> busybox at busybox.net
>> http://lists.busybox.net/mailman/listinfo/busybox