git/Documentation/git-commit-graph.txt, branch v2.48.2

doc: enforce dashes in placeholders

2023-12-26T19:06:55Z

The CodingGuidelines documents stipulates that multi-word placeholders are to be separated by dashes, not underscores nor spaces. Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

Merge branch 'ab/doc-synopsis-and-cmd-usage'

2022-10-28T18:26:54Z

The short-help text shown by "git cmd -h" and the synopsis text shown at the beginning of "git help cmd" have been made more consistent. * ab/doc-synopsis-and-cmd-usage: (34 commits) tests: assert consistent whitespace in -h output tests: start asserting that *.txt SYNOPSIS matches -h output doc txt & -h consistency: make "worktree" consistent worktree: define subcommand -h in terms of command -h reflog doc: list real subcommands up-front doc txt & -h consistency: make "commit" consistent doc txt & -h consistency: make "diff-tree" consistent doc txt & -h consistency: use "[...]" for "zero or more" doc txt & -h consistency: make "annotate" consistent doc txt & -h consistency: make "stash" consistent doc txt & -h consistency: add missing options doc txt & -h consistency: use "git foo" form, not "git-foo" doc txt & -h consistency: make "bundle" consistent doc txt & -h consistency: make "read-tree" consistent doc txt & -h consistency: make "rerere" consistent doc txt & -h consistency: add missing options and labels doc txt & -h consistency: make output order consistent doc txt & -h consistency: add or fix optional "--" syntax doc txt & -h consistency: fix mismatching labels doc SYNOPSIS & -h: use "-" to separate words in labels, not "_" ...

doc txt & -h consistency: add missing options

2022-10-13T16:32:57Z

Change those built-in commands that were attempting to exhaustively list the options in the "-h" output to actually do so, and always have *.txt documentation know about the exhaustive list of options. Let's also fix the documentation and -h output for those built-in commands where the *.txt and -h output was a mismatch of missing options on both sides. In the case of "interpret-trailers" fixing the missing options reveals that the *.txt version was implicitly claiming that the command had two operating modes, which a look at the -h version (and studying the documentation) will show is not the case. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'ab/dedup-config-and-command-docs'

2022-09-14T19:56:40Z

Share the text used to explain configuration variables used by "git " in "git help " with the text from "git help config". * ab/dedup-config-and-command-docs: docs: add CONFIGURATION sections that fuzzy map to built-ins docs: add CONFIGURATION sections that map to a built-in log docs: de-duplicate configuration sections difftool docs: de-duplicate configuration sections notes docs: de-duplicate and combine configuration sections apply docs: de-duplicate configuration sections send-email docs: de-duplicate configuration sections grep docs: de-duplicate configuration sections docs: add and use include template for config/* includes

docs: add CONFIGURATION sections that map to a built-in

2022-09-07T16:46:06Z

Add a CONFIGURATION section to the documentation of various built-ins, for those cases where the relevant config/NAME.txt describes configuration that is only used by the relevant built-in documented in git-NAME.txt. Subsequent commits will handle more complex cases. Signed-off-by: Ævar Arnfjörð Bjarmason Reviewed-by: Matheus Tavares Signed-off-by: Junio C Hamano

docs: move commit-graph format docs to man section 5

2022-08-04T21:12:23Z

Continue the move of existing Documentation/technical/* protocol and file-format documentation into our main documentation space. By moving the documentation for the commit-graph format into man section 5 and the new "developerinterfaces" category. This change is split from subsequent commits due to the relatively large amount of ASCIIDOC formatting changes that are required. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'ds/commit-graph-merging-fix'

2020-11-02T21:17:39Z

When "git commit-graph" detects the same commit recorded more than once while it is merging the layers, it used to die. The code now ignores all but one of them and continues. * ds/commit-graph-merging-fix: commit-graph: don't write commit-graph when disabled commit-graph: ignore duplicates when merging layers

commit-graph: don't write commit-graph when disabled

2020-10-09T21:16:32Z

The core.commitGraph config setting can be set to 'false' to prevent parsing commits from the commit-graph file(s). This causes an issue when trying to write with "--split" which needs to distinguish between commits that are in the existing commit-graph layers and commits that are not. The existing mechanism uses parse_commit() and follows by checking if there is a 'graph_pos' that shows the commit was parsed from the commit-graph file. When core.commitGraph=false, we do not parse the commits from the commit-graph and 'graph_pos' indicates that no commits are in the existing file. The --split logic moves forward creating a new layer on top that holds all reachable commits, then possibly merges down into those layers, resulting in duplicate commits. The previous change makes that merging process more robust to such a situation in case it happens in the written commit-graph data. The easy answer here is to avoid writing a commit-graph if reading the commit-graph is disabled. Since the resulting commit-graph will would not be read by subsequent Git processes. This is more natural than forcing core.commitGraph to be true for the 'write' process. Reported-by: Thomas Braun Helped-by: Jeff King Helped-by: Taylor Blau Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

commit-graph: introduce 'commitGraph.maxNewFilters'

2020-09-18T17:39:22Z

Introduce a configuration variable to specify a default value for the recently-introduce '--max-new-filters' option of 'git commit-graph write'. Helped-by: Junio C Hamano Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

builtin/commit-graph.c: introduce '--max-new-filters='

2020-09-18T17:35:39Z

Introduce a command-line flag to specify the maximum number of new Bloom filters that a 'git commit-graph write' is willing to compute from scratch. Prior to this patch, a commit-graph write with '--changed-paths' would compute Bloom filters for all selected commits which haven't already been computed (i.e., by a previous commit-graph write with '--split' such that a roll-up or replacement is performed). This behavior can cause prohibitively-long commit-graph writes for a variety of reasons: * There may be lots of filters whose diffs take a long time to generate (for example, they have close to the maximum number of changes, diffing itself takes a long time, etc). * Old-style commit-graphs (which encode filters with too many entries as not having been computed at all) cause us to waste time recomputing filters that appear to have not been computed only to discover that they are too-large. This can make the upper-bound of the time it takes for 'git commit-graph write --changed-paths' to be rather unpredictable. To make this command behave more predictably, introduce '--max-new-filters=' to allow computing at most '' Bloom filters from scratch. This lets "computing" already-known filters proceed quickly, while bounding the number of slow tasks that Git is willing to do. Helped-by: Junio C Hamano Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano