From: John Austin <john@astrangergravity.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: "Randall Becker" <rsbecker@nexbridge.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
id@joeyh.name, 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: Mon, 24 Sep 2018 08:34:44 -0700 [thread overview]
Message-ID: <CA+AhR6cyNqPW7YvEdanv_vA=T2oLrUm2ZyMZjLLFtdx8B+dqYQ@mail.gmail.com> (raw)
In-Reply-To: <20180924140122.GC68796@syl>
Perhaps git-global-graph is a decent name. GGG? G3? :). The structure
right now in my head looks a bit like:
Global Graph:
client - post-commit git hooks to push changes up to the GG
git server - just the standard git server configuration
query server - replies with information about the current state of the GG
Locks Pre-Commit:
client - pre-commit hook that makes requests to the GG query server
For cross-platform compatibility, the Global Graph client and the
Locks/Conflicts client are the pieces that need to be use-able on all
platforms. My goal is to keep these pieces as simple as possible. I'd
like to at least start prototyping these in Rust, hopefully in a way
that can either be easily ported or easily re-implemented in C later
on, once things are feature-frozen.
For LFS, The main points of integration with I see are:
-- bundling of packages (optionally install this package with a
normal LFS installation)
-- `git lfs locks` integration. ie. integration with the read-only
control of LFS
If we push more of the functionality into the gg query server, the
integration with `lfs locks` could be simple enough to be a couple of
web requests. That might help avoid integration issues.
> we strictly avoid using CGo
What's the main reason for this? Build system complexity?
On Mon, Sep 24, 2018 at 7:37 AM Taylor Blau <me@ttaylorr.com> wrote:
>
> On Sun, Sep 23, 2018 at 12:53:58PM -0700, John Austin 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.
>
> This would likely mean that Git LFS will have to reimplement it, since
> we strictly avoid using CGo (Go's mechanism to issue function calls to
> other languages).
>
> The upshot is that it likely shouldn't be too much effort for anybody,
> and the open-source community would get a Go implementation of the API,
> too.
>
> Thanks,
> Taylor
>
next prev parent reply other threads:[~2018-09-24 15:35 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
2018-09-23 20:43 ` Randall S. Becker
2018-09-24 14:01 ` Taylor Blau
2018-09-24 15:34 ` John Austin [this message]
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+AhR6cyNqPW7YvEdanv_vA=T2oLrUm2ZyMZjLLFtdx8B+dqYQ@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).