git VS git-lfs

Git

Before you start using Git, you need to install it on your computer. You can download and install Git from the official website (https://git-scm.com/). Once installed, open a terminal or command prompt and run the following commands to configure Git with your name and email:

Git: You should have Git installed on your machine. You can download it from the official website (https://git-scm.com/).

When working on a project together, Git is a crucial tool that help teams collaborate smoothly. One of the key features is commits, which act like snapshots of the project's progress.

Официальный сайт Git

You need Git, Docker, and a browser that's able to handle .onion addresses (e.g., Tor Browser or Brave).

> Git for Windows is built on top of msys2, which in turn is built on top of Cygwin.

you can get native Windows Git as well. its called MinGit:

https://github.com/git-for-windows/git/releases/tag/v2.42.0....

This Docker image is designed to support implementing Github Actions with Python. As of version 4.0.0., it starts with the official python docker image as the base which is a Debian OS. It specifically uses python:3-slim to keep the image size down for faster loading of Github Actions that use pyaction. On top of the base, we've installed curl gpg, git, and the GitHub CLI. We added curl and gpg because they are needed to install the GitHub CLI, and they may come in handy anyway (especially curl) when implementing a GitHub Action.

> I didn’t intend to say that «not official» means «bad».

Yes, I know, I understood that. Thank you. I was reacting to the term official, since it is an interesting question what official means for Fortran, since in a way it was "abandoned", there was the ISO committee as the only official body, but nobody wanted to provide an official place for it on the internet. So we volunteered that. In a way, I think it could already be treated as official, or if not, hopefully in a few years most people will treat it as the de-facto official. Kind of like the git webpage has migrated from https://repo.or.cz/ to https://git-scm.com/, but both in a way are unofficial, but the second one is a nice modern webpage and most people liked it and accepted it as official. I don't know the people behind either webpage.

Git can be directly installed from this website. (https://git-scm.com/)

I don’t know what that is, but their docs very prominently and strongly say this:

> However, we do not maintain a stable Go language API or ABI, as Git LFS is intended to be used solely as a compiled binary utility. Please do not import the git-lfs module into other Go code and do not rely on it as a source code dependency.

https://github.com/git-lfs/git-lfs#limitations

> I don’t know what that is

its a standard output from `go doc`, rendered as HTML. if you dont recognize that, then you aren't really in a position to be commenting on the topic. nothing is stopping anyone from pinning to a tag:

https://github.com/git-lfs/git-lfs/tags

or even a commit and relying of a specific version of the software. yes upgrades might be painful but a module IS available.

# git push origin feature-branch /usr/bin/gh auth git-credential get: 1: /usr/bin/gh auth git-credential get: /usr/bin/gh: not found /usr/bin/gh auth git-credential store: 1: /usr/bin/gh auth git-credential store: /usr/bin/gh: not found Enumerating objects: 9228, done. Counting objects: 100% (7495/7495), done. Delta compression using up to 8 threads Compressing objects: 100% (2090/2090), done. Writing objects: 100% (6033/6033), 72.77 MiB | 7.39 MiB/s, done. Total 6033 (delta 4402), reused 5194 (delta 3616) remote: Resolving deltas: 100% (4402/4402), completed with 477 local objects. remote: error: Trace: c1c90b47a5483929dcdd8c974a6c7d0695e86f67f680d8b88b80ef1c1bce74a remote: error: See https://gh.io/lfs for more information. remote: error: File deployment_20200220.sql is 872.78 MB; this exceeds GitHub's file size limit of 100.00 MB remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com. To https://github.com/my-org/my-project.git ! [remote rejected] rest-logging -> rest-logging (pre-receive hook declined) error: failed to push some refs to 'https://github.com/my-org/my-project.git'

Before commit we need to install git-lfs first, because our model.pkl file is too big. Follow the link and the instructions to install it for your operating system. Now we are able to use git-lfs for our model.pkl:

git-lfs issue

> And that pattern is the one that is used by GOs http libraries

I don't think that is correct. In https://news.ycombinator.com/item?id=34213383, I notice that Go's HTTP/2 library would write the HEADERS frame, the DATA frame, and the terminal HEADERS frame in 3 different syscalls. In a sample application using the Go's HTTP/2 library, a gRPC response without Nagle's algorithm would transmit 497 bytes over 6 packets, while a gRPC response with Nagle's algorithm would transmit 275 bytes over 2 packets.

With a starting point where both Nagle's algorithm and delayed ack are enabled, I guess this is the order of preference:

1. delayed ack disabled, applications do the right thing by buffering accordingly - ideal performance, but it is difficult to disable delayed ack, and it may require a lot of works to fix the applications.

2a. Nagle's algorithm disabled, applications do the right thing by buffering accordingly - almost ideal performance (may perform worse than #1 over bad connection), but it may require a lot of works to fix the applications.

2b. delayed ack disabled, real world applications - almost ideal performance (may have higher syscall overhead than #1), but it is difficult to disable delayed ack.

3. Nagle's algorithm disabled, real world application - not ideal as some applications can suffer from high packet overhead, e.g. git-lfs, and this is where we are at with Go.

4. baseline - far from ideal as many applications can suffer from high latency due to bad interaction between Nagle's algorithm and delayed ack.

I would say Go has made the right trade-off, albeit with a slight hint of "we know better than you". Going forward, it is probably cheaper for linux kernel to come up with a better API to disable delayed ack (i.e. to achieve #2b), than getting the affected applications to do the right thing by buffering accordingly (i.e. to achieve #1 or #2a). We will see how soon https://github.com/git-lfs/git-lfs/issues/5242 can be resolved.

In the mean time, #2b can actually be achieved with a "SRE approach" by patching the kernel to remove delayed ack and patching the Go library to remove the `setNoDelay` call. Something for OP to try?

git-lfs authors agree and point out regular git also disables Nagle.

https://github.com/git-lfs/git-lfs/issues/5242

> I will just add that it makes no sense at all that git-lfs (lf = large file!) should be sending large files 50 bytes at a time. That's a huge number of system calls that could be avoided by doing larger writes. And then the larger writes would work better for the TCP stack anyway.

FWIW, at least one git-lfs contributor agrees with you: https://github.com/git-lfs/git-lfs/issues/5242#issuecomment-...

> I think the first thing we should probably look at here is whether Git LFS (and the underlying Go libraries) are optimizing TCP socket writes or not. We should be avoiding making too many small writes where we can instead make a single larger one, and avoiding the "write-write-read" pattern if it appears anywhere in our code, so we don't have reads waiting on the final write in a sequence of writes. Regardless of the setting of TCP_NODELAY, any such changes should be a net benefit.