On 5/1/2019 3:12 PM, Ævar Arnfjörð Bjarmason wrote: > > OK, let's try that then, on top of this series: > > diff --git a/commit-graph.c b/commit-graph.c > index 5eebba6a0f..36c8cdb950 100644 > --- a/commit-graph.c > +++ b/commit-graph.c > @@ -1127,7 +1127,7 @@ int write_commit_graph(const char *obj_dir, > case 2: > hashwrite_u8(f, num_chunks); > hashwrite_u8(f, 1); /* reachability index version */ > - hashwrite_u8(f, 0); /* unused padding byte */ > + hashwrite_u8(f, 1); /* unused padding byte */ > > Then: > > $ ~/g/git/git --exec-path=$PWD commit-graph write --version=2; ~/g/git/git --exec-path=$PWD status > Expanding reachable commits in commit graph: 100% (201645/201645), done. > Computing commit graph generation numbers: 100% (200556/200556), done. > error: unsupported value in commit-graph header > HEAD detached at pr-112/derrickstolee/graph/v2-head-v3 > > So we'll error out in the same way as if "2.0" was changed to "3.0" with > this "2.1" change, just with a more cryptic error message on this new v2 > code. > > I don't see how this is meaningfully different from just bumping the > version to "3". We abort parsing the graph just like with major version > changes. Having a non-zero value here doesn't really mean "2.1" or "3". But I understand your apprehension. I'm currently working on building the incremental file format, based on this series. This "unused" byte will be used to say "how many base commit-graph files does this graph have?" If non-zero, we do not currently understand how to stitch these files together into a "combined" graph at run time, so we should fail. If we should never have an intermediate version of Git that doesn't understand this byte, then this series can wait until that feature is ready. Thanks, -Stolee
