On Mon, Mar 23, 2020 at 02:12:19PM -0600, Taylor Blau wrote: > Hi, > > In response to some discussion in [1], here is another idea instead of > '--input=none' that may make things a little clearer. Since it had been > a long time, I reminded myself that '--input=none' means > "--input=append, but don't look at packs as is usually the default". > > In [1], Gabor suggested that we could call this '--input=exists' or > '--input=existing', but I think that 'graphed' may be clearer, since > it is closer to "only _graphed_ commits". > > Another option would be to call this '--input=only-graphed', but I think > that may be overly verbose for what we're going for here. > > Let me know what you think. > > [1]: https://lore.kernel.org/git/20200322110424.GC2224@xxxxxxxxxx/ > > --- 8< --- > > In the previous commit, we introduced '--split=<no-merge|merge-all>', > and alluded to the fact that '--split=merge-all' would be useful for > callers who wish to always trigger a merge of an incremental chain. > > There is a problem with the above approach, which is that there is no > way to specify to the commit-graph builtin that a caller only wants to > include commits already in the graph. One can specify '--input=append' > to include all commits in the existing graphs, but the absence of > '--input=stdin-{commits,packs}' causes the builtin to call > 'fill_oids_from_all_packs()'. > > Passing '--input=reachable' (as in 'git commit-graph write > --split=merge-all --input=reachable --input=append') works around this > issue by making '--input=reachable' effectively a no-op, but this can be > prohibitively expensive in large repositories, making it an undesirable > choice for some users. > > Teach '--input=graphed' as an option to behave as if '--input=append' were > given, but to consider no other sources in addition. > > This, in conjunction with the option introduced in the previous patch > offers the convenient way to force the commit-graph machinery to > condense a chain of incrementals without requiring any new commits: > > $ git commit-graph write --split=merge-all --input=graphed > > Signed-off-by: Taylor Blau <me@xxxxxxxxxxxx> > --- > Documentation/git-commit-graph.txt | 8 +++++++- > builtin/commit-graph.c | 11 ++++++++--- > commit-graph.c | 6 ++++-- > commit-graph.h | 3 ++- > t/t5324-split-commit-graph.sh | 26 ++++++++++++++++++++++++++ > 5 files changed, 47 insertions(+), 7 deletions(-) > > diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-commit-graph.txt > index 0a320cccdd..4d8fbbe8ff 100644 > --- a/Documentation/git-commit-graph.txt > +++ b/Documentation/git-commit-graph.txt > @@ -39,7 +39,7 @@ COMMANDS > -------- > 'write':: > > -Write a commit-graph file based on the commits found in packfiles. > +Write a commit-graph file based on the specified sources of input: > + > With the `--input=stdin-packs` option, generate the new commit graph by > walking objects only in the specified pack-indexes. (Cannot be combined > @@ -57,6 +57,12 @@ walking commits starting at all refs. (Cannot be combined with > With the `--input=append` option, include all commits that are present > in the existing commit-graph file. > + > +With the `--input=graphed` option, behave as if `--input=append` were > +given, but do not walk other packs to find additional commits. s/walk/scan/ would be more fitting, I think. In an earlier version of these patches I asked for clarification about what happens with expired commits that are still included in the commit-graph... and I do remember that you replied to that, but, unfortunately, not what your reply was. And after reading this log message and the documentation update it's still not clear to me. > ++ > +If none of the above options are given, then generate the new > +commit-graph by walking over all pack-indexes. s/walking/scanning/ > ++ > With the `--split[=<strategy>]` option, write the commit-graph as a > chain of multiple commit-graph files stored in > `<dir>/info/commit-graphs`. Commit-graph layers are merged based on the
