Notes from the Git Contributor's Summit [LWN.net]

For those who are curious about the recently concluded Git Contributor's Summit, Taylor Blau has posted an extensive set of notes from the event. Topics include next-generation backends, libification, backward compatibility, project management, and more.

to post comments

Notes from the Git Contributor's Summit

Posted Oct 3, 2023 10:40 UTC (Tue) by aragilar (subscriber, #122569) [Link] (5 responses)

I'm surprised given the various options raised for how to store data as an alternative to git-lfs that git-annex (https://git-annex.branchable.com/) wasn't raised. I've found it ideal for managing large blobs of data (due to circumstances outside my control, I had to move a multi-TB dataset to a new storage provider twice recently, and git-annex made the migration quite easy).

Notes from the Git Contributor's Summit

Posted Oct 3, 2023 13:47 UTC (Tue) by TheGopher (subscriber, #59256) [Link]

I’m cynically inclined to say that git-annex doesn’t provide the same opportunities for monetisation.
git-lfs is very much intended to ensure your binaries are hosted in one central location and also breaks the peer to peer paradigm in git. Just my opinion though.

Notes from the Git Contributor's Summit

Posted Oct 3, 2023 16:14 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

While I do like `git-annex`, I think the symlink assumption leaves Windows out in the cold too much (unless things have changed) :/ . My favorite part is that it reuses the same channel as git itself. LFS can have desyncs with auth and knowing how to shuttle data between upstream and your fork can be a fun dance if new data was deleted since you last pushed to your fork.

Notes from the Git Contributor's Summit

Posted Oct 5, 2023 0:37 UTC (Thu) by bartoc (guest, #124262) [Link]

I mean git annex has many of the same issues as lfs, in that it doesn't store the blobs as really "part of the repository"

I think this work is really cool, being able to have multiple partial remotes and store big binaries as "just another object" means you'll never loose them, and all the fancy sparse features will "just work". The trouble is that on non-cow filesystems (NTFS probably being the most widespread) you'll still need two copies of everything.

Notes from the Git Contributor's Summit

Posted Oct 5, 2023 11:12 UTC (Thu) by farnz (subscriber, #17727) [Link]

The big problem with both git-annex and git-lfs is that they change the OID of objects stored out-of-line. This has two nasty consequences:

I can't shift between inline and out-of-line storage freely, nor can I shift freely between different out-of-line storage mechanisms.
The person committing an object has to decide whether it's stored in the git repo directly, or out-of-line; I cannot, as the person reading a repo, change that decision.

The first is obvious. The second consequence means that decisions about whether to store a file in the object database as part of the repo, and access it from the local clone, or whether to store it elsewhere, and access it over the network, have to be made correctly by the committer, and are fixed for all time - if, at the time of committing, 100 MiB is a large file, then people for whom 10 MiB is a large file are stuck, and people for whom anything under 1000 MiB should be in the local clone also get surprised when they go offline, try to check out, and discover missing objects.

Notes from the Git Contributor's Summit

Posted Nov 3, 2023 17:08 UTC (Fri) by joey (guest, #328) [Link]

I've posted some thoughts on this from a git-annex POV at https://hachyderm.io/@joeyh/111347548541634250