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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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
>
