From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org, dstolee@microsoft.com, gitster@pobox.com,
martin.agren@gmail.com, peff@peff.net
Subject: Re: [PATCH v4] builtin/commit-graph.c: support '--input=graphed'
Date: Thu, 2 Apr 2020 00:49:12 +0200 [thread overview]
Message-ID: <20200401224912.GI2224@szeder.dev> (raw)
In-Reply-To: <e0f42a2f3c0162a5d43bb2bce0f69264b59f92e9.1584994172.git.me@ttaylorr.com>
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@szeder.dev/
>
> --- 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@ttaylorr.com>
> ---
> 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
prev parent reply other threads:[~2020-04-01 22:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4e85c6f7e40e7d6a8d93574645d65971b7cfa4f8.1581486293.git.me@ttaylorr.com/>
2020-03-03 23:27 ` [PATCH v3 3/3] builtin/commit-graph.c: support '--input=none' Taylor Blau
2020-03-23 20:12 ` [PATCH v4] builtin/commit-graph.c: support '--input=graphed' Taylor Blau
2020-03-27 9:13 ` Jeff King
2020-04-01 22:49 ` SZEDER Gábor [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200401224912.GI2224@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=martin.agren@gmail.com \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).