web-dev-qa-db-fra.com

Git (LFS): qu'est-ce que le support de verrouillage? Et dois-je l'activer?

"Nouveau" commentaire Git:

Aujourd'hui même, j'ai rencontré le commentaire suivant de Git pour la première fois (au moins la première fois que je l'ai vu):

Mikes-Mac$ git Push
Locking support detected on remote "Origin". Consider enabling it with:
  $ git config 'lfs.https://github.com/<my_repo>.git/info/lfs.locksverify' true
Everything up-to-date
Mikes-Mac$

Qu'est-ce que c'est Locking support? Est-ce une sorte de verrouillage mutex pour le LFS (stockage de fichiers volumineux)? Si c'est le cas, n'est-il pas absolument essentiel de faire fonctionner git? (À tout le moins, comment établir autrement "l'ordre" de l'historique des journaux? Pire, ne pourrais-je pas avoir un fichier binaire corrompu par des écritures simultanées?)

Mes actions

Je n'ai rien fait différemment de ce référentiel récemment, et je n'ai rien fait différemment avec ce référentiel par rapport aux autres que j'ai établis avec LFS.

Je suppose donc qu'il s'agit d'un nouveau commentaire fourni au "monde" pour nous faire part de nouvelles fonctionnalités.

Pas de documentation évidente

Cependant, ni une recherche Google ni une recherche rapide dans leur documentation ne m'ont amené à quoi que ce soit pour l'expliquer. Donc, je me demande:

  • Quel est ce verrouillage?
    • Est-ce mutex? Si oui, comment mon repo pourrait-il même fonctionner sans lui?
    • Est-ce limité à seulement LFS? En quoi est-il différent du verrouillage de fichier git normal?
  • Quels sont les avantages et les inconvénients de l'ajout d'un support de verrouillage pour LFS?
gitgit-lfs
17
Mike Williamson

La prise en charge du verrouillage de Git LFS est documentée ici https://github.com/git-lfs/git-lfs/wiki/File-Locking .

Git LFS v2.0.0 inclut une première version de File Locking. Le verrouillage de fichiers permet aux développeurs de verrouiller les fichiers qu'ils mettent à jour pour empêcher d'autres utilisateurs de les mettre à jour en même temps. Les modifications simultanées dans les référentiels Git entraîneront des conflits de fusion, qui sont très difficiles à résoudre dans les gros fichiers binaires.

Une fois les modèles de fichiers dans .gitattributes sont verrouillables, Git LFS les rendra automatiquement en lecture seule sur le système de fichiers local. Cela empêche les utilisateurs de modifier accidentellement un fichier sans le verrouiller au préalable.

Git LFS vérifiera que vous ne modifiez pas un fichier verrouillé par un autre utilisateur lors de la poussée. Étant donné que File Locking est une version précoce et que peu de serveurs LFS implémentent l'API, Git LFS n'interrompra pas votre Push s'il ne peut pas vérifier les fichiers verrouillés. Vous verrez un message comme celui-ci:

$ git lfs Push Origin master --all
Remote "Origin" does not support the LFS locking API. Consider disabling it with:
  $ git config 'lfs.http://git-server.com/user/test.locksverify' false
Git LFS: (0 of 0 files, 7 skipped) 0 B / 0 B, 879.11 KB skipped

$ git lfs Push Origin master --all
Locking support detected on remote "Origin". Consider enabling it with:
  $ git config 'lfs.http://git-server.com/user/repo.locksverify' true
Git LFS: (0 of 0 files, 7 skipped) 0 B / 0 B, 879.11 KB skipped

Donc, dans un certain sens, vous pouvez le considérer comme un mutex consultatif, car:

  • Si vous ne "verrouillez" pas le fichier, vous ne pouvez pas le modifier
  • Une fois que vous "verrouillez" le fichier avec git lfs lock, vous pouvez le modifier et le serveur de référentiel reconnaîtra que vous le modifiez
  • Le serveur n'acceptera pas les validations de modification des fichiers que vous avez verrouillés par d'autres personnes.

Il est principalement ajouté pour aider l'équipe à gérer les fichiers volumineux afin d'éviter les conflits de fusion.

24
kennytm