From: Giovanni Biscuolo <g@xelera.eu>
To: "Ludovic Courtès" <ludo@gnu.org>, guix-sysadmin <guix-sysadmin@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Git-LFS or Git Annex?
Date: Wed, 24 Jan 2024 18:39:09 +0100 [thread overview]
Message-ID: <87il3i8wci.fsf@xelera.eu> (raw)
In-Reply-To: <87mssuu57m.fsf@inria.fr>
[-- Attachment #1: Type: text/plain, Size: 3933 bytes --]
Hi Ludo’
Ludovic Courtès <ludo@gnu.org> writes:
[...]
> The question boils down to: Git-LFS or Git Annex?
>
> From a quick look (I haven’t used them), Git-LFS seems to assume a
> rather centralized model where there’s an LFS server sitting next to the
> Git server¹. Git Annex looks more decentralized, allowing you to have
> several “remotes”, to check the status of each one, to sync them, etc.²
> Because of this, Git Annex seems to be a better fit.
I've never used Git-LFS for my media repository (and will never use it,
never).
AFAIK this two advantages of git-annex vs Git-LFS are still valid today:
--8<---------------cut here---------------start------------->8---
A major advantage of git annex is that you can choose which file you
want to download.
You still know which files are available thanks to the symlinks.
For example suppose that you have a directory full of ISO files. You can
list the files, then decide which one you want to download by typing:
git annex get my_file.
Another advantage is that the files are not duplicated in your
checkout. With LFS, lfs files are present as git objects both in
.git/lfs/objects and in your working repository. So If you have 20 GB of
LFS files, you need 40 GB on your disk. While with git annex, files are
symlinked so in this case only 20 GB is required.
--8<---------------cut here---------------end--------------->8---
(https://stackoverflow.com/a/43277071, 2018-10-23)
So, AFAIU, with Git-LFS you can have all your media or no media, you
cannot selectively choose what media to get.
Another important limitation of Git-LFS is that you cannot delete
(remotely stored) objects [1], with git-annex is very easy.
> Data point: guix.gnu.org source is hosted on Savannah, which doesn’t
> support Git-LFS;
to host a Git-LFS service a Git-LFS server implementation (one that
reply to GIT_LFS API) is needed:
https://github.com/git-lfs/git-lfs/wiki/Implementations
AFAIU we dont't have one packaged (I'd save some precious time trying to
package one of them).
AFAIK Savannah do not support git-annex also, so we need to set up a
Guix git-annex server [3], I suggest using gitolite [4]: I can help with
this task if needed!
> the two other web sites above are hosted on GitLab instances, which I
> think do support Git-LFS.
Yes, Git-LFS is supported on GitLab.com and included in the Community
Edition [2] since late 2015.
git-annex repository support was available on GitLab.com in 2015/16 but
was removed in 2017 [5]
> What’s your experience? What would you suggest?
I've no experience with Git-LFS (and will never have) but from what I
read I definitely suggest git-annex: it's more efficient, it's more
flexible, can be hosted everywhere with a little bit of effort... can be
hosted on a Guix System host! :-)
As a bonus, git-annex have a plenty of super cool features that will
make us very happy, i.e.:
- special remotes: https://git-annex.branchable.com/special_remotes/
(including rclone
https://git-annex.branchable.com/special_remotes/rclone/)
- location tracking
(https://git-annex.branchable.com/location_tracking/)
- manage metadata of annexed files
HTH! Gio'
> Thanks,
> Ludo’.
>
> ⁰ https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n193
> ¹ https://github.com/git-lfs/git-lfs/wiki/Tutorial
> ² https://git-annex.branchable.com/walkthrough/
[1] https://github.com/git-lfs/git-lfs/wiki/Limitations
[2] GitLab Community Edition
[3]
https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_your_own_server/
[4] https://git-annex.branchable.com/tips/using_gitolite_with_git-annex/
[5] https://about.gitlab.com/blog/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/
--
Giovanni Biscuolo
Xelera IT Infrastructures
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]
next prev parent reply other threads:[~2024-01-24 17:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 15:22 Git-LFS or Git Annex? Ludovic Courtès
2024-01-24 16:13 ` indieterminacy
2024-01-24 17:39 ` Giovanni Biscuolo [this message]
2024-01-28 10:33 ` Nicolas Graves via Development of GNU Guix and the GNU System distribution.
2024-01-28 11:32 ` Philip McGrath
2024-01-28 17:32 ` Giovanni Biscuolo
2024-01-29 11:39 ` Nicolas Graves via Development of GNU Guix and the GNU System distribution.
2024-01-24 18:41 ` pukkamustard
2024-01-24 20:32 ` Troy Figiel
2024-01-25 12:03 ` Giovanni Biscuolo
2024-01-25 16:55 ` Simon Tournier
2024-01-26 2:20 ` Kyle Meyer
2024-01-26 10:02 ` Simon Tournier
2024-01-27 16:59 ` Timothy Sample
2024-01-27 17:47 ` Kyle Meyer
2024-02-14 15:18 ` Simon Tournier
2024-01-27 4:31 ` Philip McGrath
2024-01-28 17:37 ` Efraim Flashner
2024-02-02 16:46 ` Christine Lemmer-Webber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87il3i8wci.fsf@xelera.eu \
--to=g@xelera.eu \
--cc=guix-devel@gnu.org \
--cc=guix-sysadmin@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).