This one seems simple and sensible.

That one seems simple and sensible too.

This one seems simple and sensible.

I did a first path through it, the new code seems reasonable and easier
to read than the previous one. Some comments and questions below.

I am quite enthousiastic for a non-filelog based copy tracing using commit level information. However, I am very unenthousiastic at the idea of storing more copy data in the changeset itself. The "files" field in the changelog is already quite problematic (about 95% for changelog.d file, taking possibily hundred of megabytes). In addition, stoing copy in the changeset is kind of a "schema breakage" making its adoption slower.

Thanks looks good to me. Thanks for clarifying the table.

+1

In D6140#89738, @martinvonz wrote:

In D6140#89733, @marmoute wrote:

[…]
What Martin is trying to achieve here is a simple function to express
X::X. So maybe it could be a special case of a function expression X::Y.
However, we don't have this function right now. Maybe we jut need to
introduce it, with a clear name eg revbetween or connected or
dagrange, with an optionnal second arguments:

• X::Y → dagrange(X, Y)
• X::X → dagrange(X)

And ::X and X::? Maybe dagrange(heads=X) and dagrange(roots=X), respectively? That implies that roots and heads default to null and heads(), but it seems weird that dagrange(X) is equivalent to dagrange(roots=X, heads=X).

I spend some more time thinking about it, especially about the semantic
I would expect from a contiguous function. My conclusion is that I'm
seeing something call contiguous more as a filter than something
adding element to the set.

I chatted a bit with Georges about this. He suggested something along
the line of fill or complete.

I am a fan of this function, I need this on a regular basis. Having an
explicit function for this also open the way to various optimization.
For example we know that a set already has this property we could skip
all computation.