Re: [PATCH v4 10/10] commit-graph.txt: update design document

>>>   - After computing and storing generation numbers, we must make graph
>>>     walks aware of generation numbers to gain the performance benefits they
>>>     enable. This will mostly be accomplished by swapping a commit-date-ordered
>>>     priority queue with one ordered by generation number. The following
>>> -  operations are important candidates:
>>> +  operation is an important candidate:
>>>   -    - paint_down_to_common()
>>>       - 'log --topo-order'
>>
>> Another possible candidates:
>>
>>         - remove_redundant() - see comment in previous patch
>>         - still_interesting() - where Git uses date slop to stop walking
>>           too far
>
> remove_redundant() will be included in v5, thanks.

> Instead of "still_interesting()" I'll add "git tag --merged" as the
> candidate to consider, as discussed in [1].
>
> [1] https://public-inbox.org/git/87fu3g67ry.fsf@lant.ki.iif.hu/t/#u
>     "branch --contains / tag --merged inconsistency"

>> One important issue left is handling features that change view of
>> project history, and their interaction with commit-graph feature.
>>
>> What would happen, if we turn on commit-graph feature, generate commit
>> graph file, and then:
>>
>>    * use graft file or remove graft entries to cut history, or remove cut
>>      or join two [independent] histories.
>>    * use git-replace mechanims to do the same
>>    * in shallow clone, deepen or shorten the clone
>>
>> What would happen if without re-generating commit-graph file (assuming
>> tha Git wouldn't do it for us), we run some feature that makes use of
>> commit-graph data:
>>
>>    - git branch --contains
>>    - git tag --contains
>>    - git rev-list A..B
>>
>
> The commit-graph is not supported in these scenarios (yet). grafts are
> specifically mentioned in the future work section.
>
> I'm not particularly interested in supporting these features, so they
> are good venues for other contributors to get involved in the
> commit-graph feature. Eventually, they will be blockers to making the
> commit-graph feature a "default" feature. That is when I will pay
> attention to these situations. For now, a user must opt-in to having a
> commit-graph file (and that same user has possibly opted in to these
> history modifying features).