From: Taylor Blau <me@ttaylorr.com>
Date: Mon, 17 Sep 2018 13:55:25 GMT
Subject: Re: Git for games working group
Message-ID: <20180917135525.GF71477@syl>
In-Reply-To: <878t41lcfi.fsf@evledraar.gmail.com>

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@gmail.com "refactoring all Makefiles"
>     my-random-per-repo-id 2018-09-16 0 avarab@gmail.com "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