Re: [PATCH v3 0/6] Create commit-graph file format v2

[Derrick Stolee <stolee@gmail.com>]

On 5/2/2019 2:02 PM, Ævar Arnfjörð Bjarmason wrote:
>
> But those are separate from any back-compat concerns, which is what I
> think makes sense to focus on now.

Thinking more on this topic, I think I have a way to satisfy _all_ of
your concerns by simplifying the plan for incremental commit-graph files.

My initial plan was to have the "commit-graph" file always be the "tip"
file, and it would point to some number of "graph-{hash}.graph" files.
Then, we would have some set of strategies to decide when we create a new
.graph file or when we compact the files down into the "commit-graph"
file.

This has several issues regarding race conditions that I had not yet
resolved (and maybe would always have problems).

It would be much simpler to restrict the model. Your idea of changing
the file name is the inspiration here.

* The "commit-graph" file is the base commit graph. It is always
  closed under reachability (if a commit exists in this file, then
  its parents are also in this file). We will also consider this to
  be "commit-graph-0".

* A commit-graph-<N> exists, then we check for the existence of
  commit-graph-<N+1>. This file can contain commits whose parents
  are in any smaller file.

I think this resolves the issue of back-compat without updating
the file format:

1. Old clients will never look at commit-graph-N, so they will
   never complain about an "incomplete" file.

2. If we always open a read handle as we move up the list, then
   a "merge and collapse" write to commit-graph-N will not
   interrupt an existing process reading that file.

I'll start hacking on this model.

Thanks,
-Stolee