From: Giovanni Biscuolo <g@xelera.eu>
To: Nicolas Graves <ngraves@ngraves.fr>,
guix-sysadmin <guix-sysadmin@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Git-LFS or Git Annex?
Date: Sun, 28 Jan 2024 18:32:29 +0100 [thread overview]
Message-ID: <87v87d749e.fsf@xelera.eu> (raw)
In-Reply-To: <8734uhycgs.fsf@ngraves.fr>
[-- Attachment #1: Type: text/plain, Size: 4375 bytes --]
Hi Nicolas,
Nicolas Graves <ngraves@ngraves.fr> writes:
[...]
> This is not always true. Git-LFS also has the concept of Custom Transfer
> Agents, which in some cases do not need a running server. One example is
> lfs-folderstore, which can simply use a remote directory as a LFS
> remote.
thanks, i didn't know about custom transfer agents, the use withous an
API server is documented here:
--8<---------------cut here---------------start------------->8---
In some cases the transfer agent can figure out by itself how and where
the transfers should be made, without having to query the API server. In
this case it's possible to use the custom transfer agent directly,
without querying the server, by using the following config option:
lfs.standalonetransferagent, lfs.<url>.standalonetransferagent
Specifies a custom transfer agent to be used if the API server URL
matches as in "git config --get-urlmatch lfs.standalonetransferagent
<apiurl>". git-lfs will not contact the API server. It instead sets
stage 2 transfer actions to null. "lfs.<url>.standalonetransferagent"
can be used to configure a custom transfer agent for individual
remotes. "lfs.standalonetransferagent" unconditionally configures a
custom transfer agent for all remotes. The custom transfer agent must be
specified in a "lfs.customtransfer.<name>" settings group.
--8<---------------cut here---------------end--------------->8---
(https://github.com/git-lfs/git-lfs/blob/main/docs/custom-transfers.md#using-a-custom-transfer-type-without-the-api-server)
some examples:
1. git-lfs-agent-scp: A custom transfer agent for git-lfs that uses scp
to transfer files. This transfer agent makes it possible to use
git-lfs in situations where the remote only speaks ssh. This is
useful if you do not want to install a git-lfs server. (MIT license,
written in C, URL: https://github.com/tdons/git-lfs-agent-scp)
2. git-lfs-rsync-agent: The rsync git-lfs custom transfer agent allows
transferring the data through rsync, for example using SSH
authentication. (MIT license, written in Go, URL:
https://github.com/excavador/git-lfs-rsync-agent)
3. git-lfs-agent-scp-bash: A custom transfer agent for git-lfs that uses
scp to transfer files. This is a self-contained bash script designed
for seamless installation, requiring no prerequisites with the
exception of the external command scp. It enables to use git-lfs even
if you can not use http/https but ssh only. (MIT License, written in
bash, URL: https://github.com/yoshimoto/git-lfs-agent-scp-bash)
So yes: we could use git-lfs without a git-lfs server and set an rsync
or scp transfer agent for each remote (documenting it for users, since
this must be done client-side)
It's not at all as powerful as the location tracking features of
git-annex but... doable :-)
[...]
>> Another important limitation of Git-LFS is that you cannot delete
>> (remotely stored) objects [1], with git-annex is very easy.
>
> Probably true, haven't encountered the use-case yet.
IMHO this is a very important feature when you have to manage media
archives.
[...]
> Just a note on upsides of Git-LFS :
> - integration with git is better. A special magit extension to use
> git-lfs is not needed, whereas it is with git-annex.
true :-D
> - less operations: once I know which files will be my media files, I
> have less headaches (basically the exact git experience, you don't have
> to think about where I should `git add` or `git annex add` a file).
it's the same with git-annex, you just have to configure/distribute a
.gitattributes file, i.e.:
--8<---------------cut here---------------start------------->8---
* annex.largefiles=(largerthan=5Mb)
* annex.largefiles=(not(mimetype=text/*))
--8<---------------cut here---------------end--------------->8---
see https://git-annex.branchable.com/tips/largefiles/ for a description
of this feature
> It's indeed less copyleft though. Simpler, but also maybe less adapted
> to this use-case.
With git-annex everyone can set up a "git-annex enabled" server
(although haskel dependency is a limitation since it's unsupported in
many architectures)... or use one of the available special remotes.
Thanks! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]
next prev parent reply other threads:[~2024-01-28 17:33 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
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 [this message]
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=87v87d749e.fsf@xelera.eu \
--to=g@xelera.eu \
--cc=guix-devel@gnu.org \
--cc=guix-sysadmin@gnu.org \
--cc=ngraves@ngraves.fr \
/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).