From: John Austin <john@astrangergravity.com>
To: Randall Becker <rsbecker@nexbridge.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
id@joeyh.name, "Taylor Blau" <me@ttaylorr.com>,
git@vger.kernel.org,
"brian m. carlson" <sandals@crustytoothpaste.net>,
"Lars Schneider" <larsxschneider@gmail.com>,
pastelmobilesuit@github.com
Subject: Re: Git for games working group
Date: Sun, 23 Sep 2018 12:55:00 -0700 [thread overview]
Message-ID: <CA+AhR6cRZUKL9USL3=RR0xJvntLrsh_NMAZofwT9N0jzRuutsw@mail.gmail.com> (raw)
In-Reply-To: <CA+AhR6c+D84sHhABRm4xf=5RWnpVEBXMXzdQxipYMS5bmkw9iQ@mail.gmail.com>
Regarding integration into LFS, I'd like to build the library in such
a way that it would easy to bundle with LFS (so they could share the
same git hooks), but also make it flexible enough to work for other
workflows.
On Sun, Sep 23, 2018 at 12:53 PM John Austin <john@astrangergravity.com> wrote:
>
> On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker
> <rsbecker@nexbridge.com> wrote:
> > I would even like to help with your effort and have non-unixy platforms I'd like to do this on.
> > Having this separate from git LFS is an even better idea IMO, and I would suggest implementing this using the same set of build tools that git uses so that it is broadly portable, unlike git LFS. Glad to help there too.
>
> Great to hear -- once the code is in a bit better shape I can open it
> up on github. Cross platform is definitely one of my focuses. I'm
> currently implementing in Rust because it targets the same space as C
> and has great, near trivial, cross-platform support. What sorts of
> platforms are you interested in? Windows is my first target because
> that's where many game developers live.
>
> > I would suggest that a higher-level grouping mechanism of resource groups might be helpful - as in "In need this directory" rather than "I need this file". Better still, I could see "I need all objects in this commit-ish", which would allow a revert operation to succeed or fail atomically while adhering to a lock requirement.
> > One bit that traditional lock-brokering systems implement involve forcing security attribute changes - so an unlocked file is stored as chmod a-w to prevent accidental modification of lockables, when changing that to chmod ?+w when a lock is acquired. It's not perfect, but does catch a lot of errors.
>
> Agreed -- I think this is all up to how the query endpoint and client
> is designed. A couple of different types of clients could be
> implemented, depending on the policies you want in place. One could
> have strict security that stored unlocked files with a-w, as
> mentioned. Another could be a weaker client, and simply warn
> developers when their current branch is in conflict.
next prev parent reply other threads:[~2018-09-23 19:55 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
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 [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+AhR6cRZUKL9USL3=RR0xJvntLrsh_NMAZofwT9N0jzRuutsw@mail.gmail.com' \
--to=john@astrangergravity.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=id@joeyh.name \
--cc=larsxschneider@gmail.com \
--cc=me@ttaylorr.com \
--cc=pastelmobilesuit@github.com \
--cc=rsbecker@nexbridge.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.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).