On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
> In the hypothetical git-annex-like case (simplifying a bit for the
> purposes this explanation), for every FILE in your tree you have a
> corresponding FILE.lock file, but it's not a boolean, but a log of who's
> asked for locks, i.e. lines of:
>
> <repository UUID> <ts> <state> <who (email?)> <explanation?>
>
> E.g.:
>
> $ cat Makefile.lock
> my-random-per-repo-id 2018-09-15 1 avarab@xxxxxxxxx "refactoring all Makefiles"
> my-random-per-repo-id 2018-09-16 0 avarab@xxxxxxxxx "done!"
>
> This log is append-only, when clients encounter conflicts there's a
> merge driver to ensure that all updates are kept.
Certainly. I think that there are two things that aren't well expressed
under this mechanism:
1. Having a log of locks held against that (a) file doesn't prevent us
from introducing merge conflicts at the <file>.lock level, so we're
reliant upon the caller first running 'git pull' and hoping that no
one beats them out to locking and pushing their lock.
2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
together." This isn't possible in Git LFS today with the existing "git
lfs lock" command (I had to check, but it takes only _one_ filename as
its argument).
Perhaps it would be nice to support something like this someday in
Git LFS, but I think we would have to reimagine how this would look
in your file.lock scheme.
Thanks,
Taylor
