Re: Git for games working group

From: Taylor Blau <me@ttaylorr.com>
Date: Sep 25, 2018, 20:14 UTC
Message-ID: <20180925201401.GA4364@syl>
In-Reply-To: <CA+AhR6dzOUeJ0MsAF1C9-aUUJ9v4i5uaPKzxHJAPy0ZUjYtyVA@mail.gmail.com>

On Mon, Sep 24, 2018 at 09:05:56PM -0700, John Austin wrote:

Show 8 quoted lines

> On Mon, Sep 24, 2018 at 12:58 PM Taylor Blau <me@ttaylorr.com> wrote:
> > 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).
>
> Right, that should have been another bullet point. The fact that there
> can only be one git hook is.. frustrating.

Sure, I think one approach to dealing with this is to teach Git how to handle multiple hooks for the same phase of hook.

I don't know how likely this is in practice to be something that would be acceptable, since it seems to involve much more work than either of our tools learning about the other.

> Perhaps, if LFS has an option to bundle global-graph, LFS could merge
> the hooks when installing?

Right. I think that (in an ideal world) both tools would know about the other, that way we can not have to worry about who installs what first.

Show 9 quoted lines

> If you instead install global-graph after LFS, I think it should
> probably attempt something like:
>   -- first move the existing hook to a folder: post-commit.d/
>   -- install the global-graph hook to post-commit.d/
>   -- install a new hook at post-commit that simply calls all
> executables in post-commit.d/
>
> Not sure if this is something that's been discussed, since I know LFS
> has a similar issue with existing hooks, but might be sensible.

Yeah, I think that that would be fine, too.

Thanks, Taylor