On Fri, Jun 29, 2018 at 9:13 AM Derrick Stolee <dstolee@xxxxxxxxxxxxx> wrote: > +# Construct a grid-like commit graph with points (x,y) > +# with 1 <= x <= 10, 1 <= y <= 10, where (x,y) has > +# parents (x-1, y) and (x, y-1), keeping in mind that > +# we drop a parent if a coordinate is nonpositive. > +# > +# (10,10) > +# / \ > +# (10,9) (9,10) > +# / \ / \ > +# (10,8) (9,9) (8,10) > +# / \ / \ / \ > +# ( continued...) > +# \ / \ / \ / > +# (3,1) (2,2) (1,3) > +# \ / \ / > +# (2,1) (2,1) > +# \ / > +# (1,1) > +# > +# We use branch 'comit-x-y' to refer to (x,y). > +# This grid allows interesting reachability and > +# non-reachability queries: (x,y) can reach (x',y') > +# if and only if x' <= x and y' <= y. This is an interesting DAG, though not very common in reality (81 merges, 18 single parent commits, one root with a depth of at most 10). It reminds me of FELINE as that also has 2 independent numbers :) I guess it is easy to make up artificial test cases for that, but I wonder if we want more variety for a generic reachability test tool (e.g. long chains of parallel histories, octopus, disconnected parts of the graph) > +test_expect_success 'setup' ' [...] > + git commit-graph write --reachable Is this only to test the full commit-graph?, maybe we'd want to write out the commit graph at (5,10) or so, such that half the walking is tested without graph. What about author/commit dates?
