Re: Git for games working group

From: Taylor Blau <me@ttaylorr.com>
Date: Sep 24, 2018, 19:58 UTC
Message-ID: <20180924195840.GG68796@syl>
In-Reply-To: <CA+AhR6cyNqPW7YvEdanv_vA=T2oLrUm2ZyMZjLLFtdx8B+dqYQ@mail.gmail.com>

On Mon, Sep 24, 2018 at 08:34:44AM -0700, John Austin wrote:

Show 5 quoted lines

> 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

I'm replying to this part of the email to note that this would cause Git LFS to have to do some extra work, since running 'git lfs install' already writes to .git/hooks/post-commit (ironically, to detect and unlock locks that we should have released).

I'm not immediately sure about how we'd resolve this, though I suspect it would look like either of:

  - Git LFS knows how to install or _append_ hooks to a given location,
    should one already exist at that path on disk, or

  - git-global-graph knows how to accommodate Git LFS, and can include a
    line that calls 'git-lfs-post-commit(1)', perhaps via:

      $ git global-graph install --git-lfs=$(which git-lfs)

    or similar.

Show 5 quoted lines

> 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

Sounds sane to me.

> > we strictly avoid using CGo
>
> What's the main reason for this? Build system complexity?

A couple of reasons. CGO is widely considered to be (1) slow and (2) unsafe. For our purposes, this would almost be OK, except that it makes it impossible for me to build cross-platform binaries without the correct compilers installed.

Today, I build Git LFS for every pair in {Windows, Darwin, Linux, FreeBSD} x {386, amd64} by running 'make release', and using CGO would not allow me to do that.

Transitioning from Go to CGO during each call is notoriously expensive, and concedes many of the benefits that leads us to choose Go in the first place. (Although now that I write much more C than Go, I don't think I would make the same argument today ;-).)

Thanks, Taylor