I observe a slowdown during commit while I have lfs hooks installed. The lag (roughly 120ms) delays the commit msg window (vi), so is noticeable as I am waiting to type.

Intriguing ... I wonder which of our hooks could be contributing to that? We install four hook programs, by default, but none of them is a pre-commit hook program.

If create a small test repository and run GIT_TRACE=1 git commit on a commit with a Git LFS object, I don't see any of our programs being invoked before vim(1):

$ git init test
$ cd test
$ git lfs track "*.bin"
$ echo foo >foo.bin
$ git add .gitattributes foo.bin
$ GIT_TRACE=1 git commit

21:34:53.443693 run-command.c:673       trace: run_command: GIT_INDEX_FILE=.git/index vim /private/tmp/test/.git/COMMIT_EDITMSG
21:34:53.443811 run-command.c:765       trace: start_command: /usr/bin/vim /private/tmp/test/.git/COMMIT_EDITMSG
...

Our post-commit does run after I close the editor, of course, but that doesn't delay the editor opening in the first place.

Out of interest, what do you see if you run GIT_TRACE=1 git commit?

On the topic of our Git LFS hook programs, I should note that unless you are using the --lockable option of the git lfs track command to assign the lockable attribute to file path patterns, and then expecting commands like git lfs checkout and git lfs merge to adjust the write permissions of files you haven't locked with git lfs lock, you don't actually need three of our four hook programs to perform any actions.

The purpose of our post-checkout, post-commit, and post-merge hook programs is solely to adjust the write permissions of files based on their lock state, so if you aren't using that Git LFS feature at all, you can disable them by setting the lfs.setLockableReadOnly configuration option or the GIT_LFS_SET_LOCKABLE_READONLY environment variable to false. The hook scripts and programs will still run, of course, but at least the git-lfs binary will exit immediately in this case.

Our pre-push hook program is not something which can be disabled, however, as it's a crucial part of the upload process for Git LFS objects.

The change in this PR sped the hook by 30ms on my MacBook Pro M2 (25ms for the git-lfs part, 5ms for exec). Not that significant, but I thought I'd share it.

That's interesting, thank you!

I have an slightly older MacBook Pro (an M1) and I tried running our post-checkout hook script repeatedly while tinkering with it, and I can't say I saw much difference. (With no arguments, the git-lfs post-checkout command just prints an error message and exits, so we're able to just focus on the startup costs.)

The first few runs would sometimes have a slower outlier by 50ms or so, but I assume there's some OS-level caching of path lookups which accounts for this.

First, running git-lfs post-checkout as a bare command, I get pretty consistent runtimes of ~65 ms:

$ time git-lfs post-checkout
This should be run through Git's post-checkout hook.  Run `git lfs update` to install it.

real	0m0.065s
user	0m0.027s
sys		0m0.023s

Running our standard post-checkout hook script adds about another ~12 ms:

$ time ./post-checkout 
This should be run through Git's post-checkout hook.  Run `git lfs update` to install it.

real	0m0.077s
user	0m0.033s
sys		0m0.028s

There's not much difference after replacing git lfs with git-lfs and maybe a slight improvement with exec git-lfs; I've put some sample runtimes below. (Since I'm on macOS I'm using the BSD flavour of sed(1) where the -i option works differently than for the GNU version.)

$ cp post-checkout post-checkout-test
$ sed -i '' -e 's/^git lfs/git-lfs/' post-checkout-test
$ time ./post-checkout-test 
This should be run through Git's post-checkout hook.  Run `git lfs update` to install it.

real	0m0.075s
user	0m0.029s
sys		0m0.027s

$ sed -i '' -e 's/^git-lfs/exec git-lfs/' post-checkout-test
$ time ./post-checkout-test 
This should be run through Git's post-checkout hook.  Run `git lfs update` to install it.

real	0m0.072s
user	0m0.029s
sys		0m0.026s

To be honest, though, these are just some roughly representative examples of the average runtimes, and there was a lot of variation.

Each different alternative (i.e., git lfs, git-lfs, and exec git-lfs) produced a range of runtimes between about 60–80 ms just on its own, and so that variance overshadowed whatever small differences there were in the average runtimes between the three alternatives.

Uh oh!

Shell optimization for repo hooks #6130

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions