From: Taylor Blau <me@ttaylorr.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Taylor Blau <me@ttaylorr.com>,
John Austin <john@astrangergravity.com>,
git@vger.kernel.org, sandals@crustytoothpaste.net,
larsxschneider@gmail.com, pastelmobilesuit@github.com,
Joey Hess <id@joeyh.name>
Subject: Re: Git for games working group
Date: Mon, 17 Sep 2018 11:57:32 -0400 [thread overview]
Message-ID: <20180917155732.GI71477@syl> (raw)
In-Reply-To: <874leokw3p.fsf@evledraar.gmail.com>
On Mon, Sep 17, 2018 at 05:00:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > 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.
>
> If you can do it for 1 file you can do it for N with a for-loop, no? So
> is this just a genreal UI issue in git-annex where some commands don't
> take lists of filenames (or git pathspecs) to operate on, or a more
> general issue with locking?
I think that it's more general.
I envision a scenario where between iterations of the for-loop, another
client acquires a lock later on in the list. I think that the general
problem here is that there is no transactional way to express "please
give me all N of these locks".
Thanks,
Taylor
next prev parent reply other threads:[~2018-09-17 15:57 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-14 17:55 Git for games working group John Austin
2018-09-14 19:00 ` Taylor Blau
2018-09-14 21:09 ` John Austin
2018-09-15 16:40 ` Taylor Blau
2018-09-16 14:55 ` Ævar Arnfjörð Bjarmason
2018-09-16 20:49 ` John Austin
2018-09-17 13:55 ` Taylor Blau
2018-09-17 14:01 ` Randall S. Becker
2018-09-17 15:00 ` Ævar Arnfjörð Bjarmason
2018-09-17 15:57 ` Taylor Blau [this message]
2018-09-17 16:21 ` Randall S. Becker
2018-09-17 16:47 ` Joey Hess
2018-09-17 17:23 ` Ævar Arnfjörð Bjarmason
2018-09-23 17:28 ` John Austin
2018-09-23 17:56 ` Randall S. Becker
2018-09-23 19:53 ` John Austin
2018-09-23 19:55 ` John Austin
2018-09-23 20:43 ` Randall S. Becker
2018-09-24 14:01 ` Taylor Blau
2018-09-24 15:34 ` John Austin
2018-09-24 19:58 ` Taylor Blau
2018-09-25 4:05 ` John Austin
2018-09-25 20:14 ` Taylor Blau
2018-09-24 13:59 ` Taylor Blau
2018-09-14 21:13 ` John Austin
2018-09-16 7:56 ` David Aguilar
2018-09-17 13:48 ` Taylor Blau
2018-09-14 21:21 ` Ævar Arnfjörð Bjarmason
2018-09-14 23:36 ` John Austin
2018-09-15 16:42 ` Taylor Blau
2018-09-16 18:17 ` John Austin
2018-09-16 22:05 ` Jonathan Nieder
2018-09-17 13:58 ` Taylor Blau
2018-09-17 15:58 ` Jonathan Nieder
2018-10-03 12:28 ` Thomas Braun
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180917155732.GI71477@syl \
--to=me@ttaylorr.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=id@joeyh.name \
--cc=john@astrangergravity.com \
--cc=larsxschneider@gmail.com \
--cc=pastelmobilesuit@github.com \
--cc=sandals@crustytoothpaste.net \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.