I think there are two issues here. The format string in line 500 doesn't match 492 and the format string in 494 doesn't either.

This is a proof-of-concept still, not for actual merge.

default should be fine. There are a number of places that don't necessarily work correctly for miss-ordered parents, but that's been the default behavior for years too, so nothing new.

Oh, sorry. I thought you returned the slice directly, which should avoid some extra memory allocations.

Well, for DOS-style line ending, the find will point to the \n and we should return everything before the \r. If we ignore line endings mixed with old Mac-style, just checking the character before is enough to cover both DOS and Unix convention.

Note that you should at least try to check if text[i-1] is \r, otherwise the result changes from before. I'm perfectly fine with not supporting the ancient Mac convention of using \r only, but we should work properly for DOS-style \r\n.

I wonder if we shouldn't optimize for the common case of multiple lines by using find() instead. Searching for \n first and \r second (in the substring if the first got a hit) and only then slicing the result.

Why not pickable = sorted(heads)?

Please fix the comment to something like: Python 3 file objects set the initial position consistently for append mode and can be used directly or something like that. The current comment doesn't make sense without the context.

Why do we want this variant of a rank? E.g. an alternative definition of rank is the length of the longest path to root. That definition is much easier to compute incrementally and just as useful for most algorithmic uses.

Most of v1 and v2 is shared and duplicating all of that just adds complications for no gain.

This is reasonable, but I didn't double-check that all cases are identical.

I'm not a fan of this change, it seems a step in the wrong direction.

"fast to general locally" in the description needs a fix. I wonder if we should introduce a new set for such features, I expect similar cases to occur in the future.

From the VC call today: The use case can be addressed by marking parents as to-be-preserved, so that for merge commits rebase can decide on the parent link is should operate on. It covers a general DAG and is somewhat easier to use in terms of UX than the parentmap, but can provide the same functionality with a multi-step rebase.

I would have to reaudit the parents use, but it wasn't just new code that misbehaves on misordered parents. E.g. memctx.parents for a trivial example. So yes, just backing it out introduces regressions as well.

Just the revert as is introduces other regressions. At the very least, we should preserve the sorting for changelog and keep the original order for filelog. The other part is that the filelog logic here is actively broken even before, so this doesn't fix the logic, just makes it less visibly broken.

Can you comment on how many of them we keep open at a time?

Consider it more a -0, not a very strong objection.

Correct, this stack should have beeen superseded by those.

There are three stages for the revlog and I think we need to teach the transaction playback code at least a bit about this to handle it correctly:

This whole stack exposes a real problem and one quite a bit older, but it is not correct in a number of ways as is.

Silly Python, but this should be fine for all versions we care about. Ironically, it used to be defined the other way around as alias...

Adding more files to the revlog layer sounds like a move in the wrong direction and the motivation here seems quite weak too. Please discuss this with an actual plan on the mailing list.

I don't understand the motivation for this change.

I don't understand this change. We already support none as compression method.

This adds a penalty for the non-inline case?

I'm not sure that this is an improvement. We discussed whether we want to hard-wire the version even stricter ("exactly version 11"), especially because it is hard to predict when the output is going to change again.

Already merged as d55b71393907

Merged as 8d2b62d716b0

Merged as 77e73827a02d