Derrick Stolee <stolee@xxxxxxxxx> writes: > On 5/29/2018 12:27 AM, Junio C Hamano wrote: >> Derrick Stolee <dstolee@xxxxxxxxxxxxx> writes: >> >>> Thanks for all the feedback on v2. I've tried to make this round's >>> review a bit easier by splitting up the commits into smaller pieces. >>> Also, the test script now has less boilerplate and uses variables and >>> clear arithmetic to explain which bytes are being modified. >>> >>> One other change worth mentioning: in "commit-graph: add '--reachable' >>> option" I put the ref-iteration into a new external >>> 'write_commit_graph_reachable()' method inside commit-graph.c. This >>> makes the 'gc: automatically write commit-graph files' a simpler change. >> I finally managed to find time to resolve conflicts this topic has >> with other topics (of your own included, if I am not mistaken). >> Please double check the resolution when I push out the day's >> integration result later today. > > Sorry about the confusion. I was operating on my copy of > ds/generation-numbers (34fdd43339) but fetching just now I see you > updated that branch to 1472978ec6. I reset my local branch to > ds/commit-graph-fsk (53dd1e6600). The only diff I see between my v3 > branch and that commit are the changes from > ds/commit-graph-lockfile-fix (33286dcd6d). Sorry for a confusing/confused comment. The topic I had in mind that I saw interactions with this one was the per-in-core-repo allocation (sb/object-store-alloc), which was not yours. In any case, what I wanted to see sanity checked was the result of the merge into 'pu' (which needed some semantic adjustment), not individual patches on the topic branch. Relative to what we see at the tip of 'pu' right now, what I'll be pushing out in 3 or 4 hours will gain yet another semantic adjustment, so you may want to wait a bit more to avoid duplicated work. Thanks.
