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.
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
