Re: [PATCH v2 2/6] commit-graph: always parse before commit_graph_data_at()
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Feb 3, 2021, 17:37 UTC
- Message-ID
- <CAPig+cTMcNjJVyTb1mio+Pof46G3fXxurrtMiwO4h8DWi8Eu2A@mail.gmail.com>
- In-Reply-To
- <YBrCli7AR/XrB3Pr@nand.local>
On Wed, Feb 3, 2021 at 10:55 AM Taylor Blau <me@ttaylorr.com> wrote:
Show 15 quoted lines
> On Tue, Feb 02, 2021 at 10:07:32PM -0500, Derrick Stolee wrote: > > 'clear' is probably fine. I was thinking it might be good to have > > an option to the 'write' subcommand to clear the existing data, but > > it's probably better as separate steps. > > Wouldn't 'git commit-graph write --split=replace --reachable' do the > same thing? I know that you changed some of the spots where we load an > existing commit graph, so my claim might be out-of-date, but I'm pretty > sure that this would get you out of a broken state. > > Thinking aloud, I'm not totally sure that we should be exposing "git > commit-graph clear" to users. The only time that you'd want to run this > is if you were trying to remove a corrupted commit-graph, so I'd rather > see guidance on how to do that safely show up in > Documentation/git-commit-graph.txt.
Throwing one more idea into the mix, git-worktree recently got a `repair` subcommand. Even though it presently repairs a small set of problems, the subcommand name is intentionally generic so as to provide room for growth. One could imagine `git commit-graph repair` being added to provide a user-friendly mechanism for recovering from commit-graph damage.