On 21 April 2020 14:14:50 CEST, Yannik Sembritzki <[email protected]> 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 >>> [email protected] >>> http://lists.busybox.net/mailman/listinfo/busybox >> >> >> >> _______________________________________________ >> busybox mailing list >> [email protected] >> http://lists.busybox.net/mailman/listinfo/busybox _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
