From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>,
git@vger.kernel.org, me@ttaylorr.com, peff@peff.net,
abhishekkumar8222@gmail.com, "Taylor Blau" <ttaylorr@github.com>,
"Derrick Stolee" <derrickstolee@github.com>,
"Derrick Stolee" <dstolee@microsoft.com>
Subject: Re: [PATCH v2 2/6] commit-graph: always parse before commit_graph_data_at()
Date: Sun, 07 Feb 2021 21:55:35 -0800 [thread overview]
Message-ID: <xmqq8s7z6r3c.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <74f1eeab-3211-71e5-c83c-19c0b7c0257d@gmail.com> (Derrick Stolee's message of "Sun, 7 Feb 2021 21:01:44 -0500")
Derrick Stolee <stolee@gmail.com> writes:
> The reflog _might_ have something of value there, but the hope is
> that very few commits are actually being force-pushed away. The focus
> is to prioritize the deep history, and it would definitely be an
> anti-pattern if the commits in the reflog are so numerous that they
> must be tracked by the commit-graph. Of course, skipping the --reachable
> option enables a way to gather these commits as necessary.
Sure. As long as gaps in commit-graph coverage only affect
performance and never correctness (e.g. even if the things that are
only reachable from reflog entries are not covered by commit-graph,
when 'git prune' wants to know if an object can safely pruned, we
will correctly say "no, do not prune it yet"), that is perfectly fine.
next prev parent reply other threads:[~2021-02-08 5:58 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-01 17:15 [PATCH 0/5] Generation Number v2: Fix a tricky split graph bug Derrick Stolee via GitGitGadget
2021-02-01 17:15 ` [PATCH 1/5] commit-graph: use repo_parse_commit Derrick Stolee via GitGitGadget
2021-02-01 17:32 ` Taylor Blau
2021-02-01 17:15 ` [PATCH 2/5] commit-graph: always parse before commit_graph_data_at() Derrick Stolee via GitGitGadget
2021-02-01 18:44 ` Junio C Hamano
2021-02-01 17:15 ` [PATCH 3/5] commit-graph: validate layers for generation data Derrick Stolee via GitGitGadget
2021-02-01 17:39 ` Taylor Blau
2021-02-01 18:10 ` Derrick Stolee
2021-02-01 17:15 ` [PATCH 4/5] commit-graph: be extra careful about mixed generations Derrick Stolee via GitGitGadget
2021-02-01 18:04 ` Taylor Blau
2021-02-01 18:13 ` Derrick Stolee
2021-02-01 18:55 ` Junio C Hamano
2021-02-01 17:15 ` [PATCH 5/5] commit-graph: prepare commit graph Derrick Stolee via GitGitGadget
2021-02-01 18:25 ` Taylor Blau
2021-02-02 3:01 ` [PATCH v2 0/6] Generation Number v2: Fix a tricky split graph bug Derrick Stolee via GitGitGadget
2021-02-02 3:01 ` [PATCH v2 1/6] commit-graph: use repo_parse_commit Derrick Stolee via GitGitGadget
2021-02-02 3:01 ` [PATCH v2 2/6] commit-graph: always parse before commit_graph_data_at() Derrick Stolee via GitGitGadget
2021-02-03 1:08 ` Jonathan Nieder
2021-02-03 1:35 ` Derrick Stolee
2021-02-03 1:48 ` Jonathan Nieder
2021-02-03 3:07 ` Derrick Stolee
2021-02-03 15:34 ` Taylor Blau
2021-02-03 17:37 ` Eric Sunshine
2021-02-03 18:41 ` Junio C Hamano
2021-02-03 21:08 ` Taylor Blau
2021-02-03 2:06 ` Junio C Hamano
2021-02-03 3:09 ` Derrick Stolee
2021-02-07 19:04 ` SZEDER Gábor
2021-02-07 20:12 ` Junio C Hamano
2021-02-08 2:01 ` Derrick Stolee
2021-02-08 5:55 ` Junio C Hamano [this message]
2021-02-02 3:01 ` [PATCH v2 3/6] commit-graph: validate layers for generation data Derrick Stolee via GitGitGadget
2021-02-02 3:01 ` [PATCH v2 4/6] commit-graph: compute generations separately Derrick Stolee via GitGitGadget
2021-02-02 3:01 ` [PATCH v2 5/6] commit-graph: be extra careful about mixed generations Derrick Stolee via GitGitGadget
2021-02-02 3:01 ` [PATCH v2 6/6] commit-graph: prepare commit graph Derrick Stolee via GitGitGadget
2021-02-02 3:08 ` [PATCH v2 0/6] Generation Number v2: Fix a tricky split graph bug Taylor Blau
2021-02-11 4:44 ` Abhishek Kumar
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq8s7z6r3c.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=abhishekkumar8222@gmail.com \
--cc=derrickstolee@github.com \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=jrnieder@gmail.com \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
--cc=stolee@gmail.com \
--cc=szeder.dev@gmail.com \
--cc=ttaylorr@github.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).