4 ms·

Author of the post here. I think Git upstream is trying to simplify configuration. They have a config option called `features.manyFiles` which enables most of

by ublaze 6y ago

Author of the post here. I think Git upstream is trying to simplify configuration. They have a config option called `features.manyFiles` which enables most of the features we enabled for our developers (https://git-scm.com/docs/git-config#Documentation/git-config.txt-featuremanyFiles https://git-scm.com/docs/git-config#Documentation/git-config...). We wanted to use this instead of deploying a wrapper, but it turns out that some of Git's features like fsmonitor do not interact well with repositories with submodules (there were Git crashes). And we have some developers that work on repositories with submodules. So we needed something more flexible, like enabling these features only on particular repositories.

dundarious 6y ago
I’m quite confused as to what you actually shipped to your developers to increase performance. This config option is a great place to start, but it would be great if that were clearer, so that others could follow suit.
- ublaze 6y ago
  We shipped a wrapper that tweaks git configs and logs metrics, and a custom fsmonitor hook that was slightly faster than the stock one. We also ensured watchman was installed on developers laptops. And we made a few changes to Git to fix bugs (for example, `git stash` wasn't using fsmonitor data, so it was slow).
  - dundarious 6y ago
    It would be great to have a listing of those config tweaks, even if with caveats attached, such as “causes issues with submodule”. I don’t want to seem demanding, but it’s such a tantalizing article without this info :)
    - ublaze 6y ago
      Sure. core.fsmonitor is set to our custom fsmonitor (this causes issues with submodules, at least on 2.24) core.untrackedCache true We use index version 4 And a slight hack: our wrapper sets GIT_FORCE_UNTRACKED_CACHE = 1. This forces `git status` to write the untracked cache if it notices a difference. I was too lazy to add a patch to configure that.
      - dundarious 6y ago
        Wonderful, thank you!
WorldMaker 6y ago
Most of Microsoft's Scalar tool is also a thin wrapper around existing git configuration or just task scheduling upstream git operations with currently no or minimal config UI and Microsoft's blog posts talk about what isn't a thin wrapper around auto-configuration is stuff they are working to upstream directly to git eventually (assuming it makes sense to be in git upstream; GVFS for instance is considered out of scope, and git likely won't ever have a background task scheduler). Since Scalar is open source, it can be a useful reference for git settings to try in large repositories. I know that if I need to remember how to configure git's sparse "cone" checkouts, Scalar is where I'd look rather than try to manually configure it directly in git's config files.
setheron 6y ago
Do they have any recommendations on at what size to enable that?

by ublaze 6y ago

dundarious 6y ago

I’m quite confused as to what you actually shipped to your developers to increase performance. This config option is a great place to start, but it would be great if that were clearer, so that others could follow suit.

ublaze 6y ago
We shipped a wrapper that tweaks git configs and logs metrics, and a custom fsmonitor hook that was slightly faster than the stock one. We also ensured watchman was installed on developers laptops. And we made a few changes to Git to fix bugs (for example, `git stash` wasn't using fsmonitor data, so it was slow).
- dundarious 6y ago
  It would be great to have a listing of those config tweaks, even if with caveats attached, such as “causes issues with submodule”. I don’t want to seem demanding, but it’s such a tantalizing article without this info :)
  - ublaze 6y ago
    Sure. core.fsmonitor is set to our custom fsmonitor (this causes issues with submodules, at least on 2.24) core.untrackedCache true We use index version 4 And a slight hack: our wrapper sets GIT_FORCE_UNTRACKED_CACHE = 1. This forces `git status` to write the untracked cache if it notices a difference. I was too lazy to add a patch to configure that.
    - dundarious 6y ago
      Wonderful, thank you!

WorldMaker 6y ago

Most of Microsoft's Scalar tool is also a thin wrapper around existing git configuration or just task scheduling upstream git operations with currently no or minimal config UI and Microsoft's blog posts talk about what isn't a thin wrapper around auto-configuration is stuff they are working to upstream directly to git eventually (assuming it makes sense to be in git upstream; GVFS for instance is considered out of scope, and git likely won't ever have a background task scheduler). Since Scalar is open source, it can be a useful reference for git settings to try in large repositories. I know that if I need to remember how to configure git's sparse "cone" checkouts, Scalar is where I'd look rather than try to manually configure it directly in git's config files.

setheron 6y ago

Do they have any recommendations on at what size to enable that?