On Thu, Oct 24, 2019 at 06:39:51AM -0400, Derrick Stolee wrote:

quoted

quoted

Instead, I finally arrived on the conclusion that I should use a flag
that is not used in any other part of the code. In commit-reach.c, a
number of flags were defined for commit walk algorithms. The REACHABLE
flag seemed like it made the most sense, and it seems it was not
actually used in the file. The REACHABLE flag was used in early versions
of commit-reach.c, but was removed by 4fbcca4 (commit-reach: make
can_all_from_reach... linear, 2018-07-20).

Add the REACHABLE flag to commit-graph.c and use it instead of
UNINTERESTING in close_reachable(). This fixes the bug in manual
testing.

I'm inclined to agree that using a flag that is not used anywhere else
is the safest thing to do, and at -rcX time safest is good.  I'm not
sure whether it's the right thing to do in the long term, though.

Furthermore, calling this flag REACHABLE is misleading, because the
code actually means SEEN.
Consider the following sequence of commands:

  # Create a pack with two commits
  $ git commit --allow-empty -m one &&
  $ git commit --allow-empty -m two &&
  $ git repack -ad &&
  # Make one of those commits unreachable
  $ git reset --hard HEAD^ &&
  # Not even from reflogs!
  $ git reflog expire --expire-unreachable=now --all
  # Now write a commit-graph from that pack file
  $ git commit-graph write
  Computing commit graph generation numbers: 100% (2/2), done.

It added two commits to the commit-graph, although one of them is
clearly not reachable anymore, so marking it as REACHABLE while
enumerating all commits feels wrong.

Since you are using "git commit-graph write", the command is scanning
all pack-files for commits to include. Even in this case, the
close_reachable() method needs to walk to see if any commits are missing.
(It could be that the root commit is loose for some strange reason.)

In this case, we are marking REACHABLE the commits that can be reached
from our "starting" commits. In your example we start with every commit.

That's exactly my point.  fsck already uses the REACHABLE flag to mark
objects that are reachable not only from all refs (including the HEADs
of all worktrees), but their reflogs and the index as well.

However, in close_unreachable() we start with a bunch of commits and
then go into a loop adding their parents to an array, while marking
each parent to prevent them from being added multiple times in a mergy
history.  We have a good couple of similar traversals in our code
base, and in revision.c, builtin/describe.c, walker.c,
negotiator/default.c (and at this point I stopped looking) we mark
those parents as SEEN.

On a somewhat related note: 'git commit-graph write --reachable'
doesn't include HEAD; should it?

If you had used `git commit-graph write --stdin-packs` and provided a
small pack name over stdin, the concept would be similar and even more
pronounced: the pack (perhaps downloaded via 'fetch') is not likely to
contain every commit, so we need to walk all reachable commits from
those included.

I'll have a v3 today with the requested fixes.

Thanks,
-Stolee