Search code examples
gitvisual-studio-2022

What are the pros and cons of turning on commit-graph algorithm for git in visual studio

Whenever I open up VS and do something with git, I see the "Speed up your git experience in Visual Studio by enabling the commit-graph algorithm".

Unfortunately, I don't see any guidance on why to turn it on or why I wouldn't turn it on (or why it wasn't turned on automatically).

Can anyone explain what up with it?

Solution

  • If you are using it with Visual Studio (17.2 Preview 3 or later), make sure to use Git 2.46 (Q3 2024), batch 19: the Bloom filter used for path limited history traversal was broken on systems whose "char" is unsigned; update the implementation and bump the format version to 2.

    Note that you can specify in your Git repository to use or not that feature: it will be picked up by Visual Studio.

    See commit 9c8a9ec, commit 5421e7c, commit df3df2d, commit ba5a81d, commit 638e170, commit b2cf331, commit 5b5d5b5, commit ea0024d, commit 08b6ae3, commit 57982b8, commit a09858d, commit 460b156, commit cf73936, commit 1343c89, commit f88611c (25 Jun 2024) by Taylor Blau (ttaylorr).
    See commit 23e91c0 (25 Jun 2024) by Jonathan Tan (jhowtan).
    (Merged by Junio C Hamano -- gitster -- in commit ecf7fc6, 08 Jul 2024)

    repo-settings: introduce commitgraph.changedPathsVersion

    Signed-off-by: Jonathan Tan
    Signed-off-by: Taylor Blau

    A subsequent commit will introduce another version of the changed-path filter in the commit graph file.
    In order to control which version to write (and read), a config variable is needed.

    Therefore, introduce this config variable.
    For forwards compatibility, teach Git to not read commit graphs when the config variable is set to an unsupported version.
    Because we teach Git this, commitgraph.readChangedPaths is now redundant, so deprecate it and define its behavior in terms of the config variable we introduce.

    This commit does not change the behavior of writing (Git writes changed path filters when explicitly instructed regardless of any config variable), but a subsequent commit will restrict Git such that it will only write when commitgraph.changedPathsVersion is a recognized value.

    git config now includes in its man page:

    Deprecated. Equivalent to commitGraph.changedPathsVersion=-1 if true, and commitGraph.changedPathsVersion=0 if false.
    (If commitGraph.changedPathVersion is also set, commitGraph.changedPathsVersion takes precedence.)

    commitGraph.changedPathsVersion

    Specifies the version of the changed-path Bloom filters that Git will read and write. May be -1, 0 or 1.
    Note that values greater than 1 may be incompatible with older versions of Git which do not yet understand those versions. Use caution when operating in a mixed-version environment.

    Defaults to -1.

    • If -1, Git will use the version of the changed-path Bloom filters in the repository, defaulting to 1 if there are none.

    • If 0, Git will not read any Bloom filters, and will write version 1 Bloom filters when instructed to write.

    • If 1, Git will only read version 1 Bloom filters, and will write version 1 Bloom filters.

    See git commit-graph for more information.

    And:

    gitformat-commit-graph: describe version 2 of BDAT

    Signed-off-by: Jonathan Tan
    Signed-off-by: Taylor Blau

    The code change to Git to support version 2 will be done in subsequent commits.

    gitformat-commit-graph now includes in its man page:

    • Version of the hash algorithm being used. We currently support value 2 which corresponds to the 32-bit version of the murmur3 hash

    gitformat-commit-graph now includes in its man page:

    Version 1 Bloom filters have a bug that appears when char is signed and the repository has path names that have characters >= 0x80; Git supports reading and writing them, but this ability will be removed in a future version of Git.

    Why wouldn't I want to use it?

    This is described in "Supercharge your Git experience in VS" by Taysser Gherfal:

    We’ve observed an average of 70% performance improvement in loading branch history in the Git repository window for a repository with 332k commits when enabling the commit graph in Visual Studio.

    I do not think it would matter for a small repository (with small number of commits).