[Gnu-arch-users] Re: Sub-optimal ordering of rev-building in star-merge

[Stefan Monnier]

>> - Aha the latest is 142, so let's built that.
>> - Aha the common ancestor is 135 so let's build that.
>> Since the second came after the first, 142 was build from 59 by applying
>> patches 60->142, while 135 was built from 59 as well by applying patch
60-> 135.
>> Obviously, in this case the two steps should have been done in the
>> opposite order.  This was with tla-1.2

> I hate that too, but it's impossible to know that 135 is the common ancestor
> before retrieving 142.

Oooh... right! 142 might include some merge done in the other direction,
I didn't think of that.
But it seems like a "rare" event so maybe it'd be worth it to do:
- compute the apparent ancestor, assuming no merges happened on the "to be
  merged" branch.  In this case 135.
- if that apparent ancestor is on the way to 142, fetch it before
  fetching 142.
- when that's done, get back to the previous code: look for the actual
  ancestor, fetch it, merge, ...

Of course, this assumes there is a library and it's sparse.

> But it is being remedied: when my patches are merged, it will produce 135 by
> building backwards from 142.

Yes, that's better (tho not as good as my suggestion above).
I'm eagerly waiting for it (for other situations as well).

> If you have disk space to burn, you can use a non-sparse greedy revision
> library, so that when you need 135, it's available.

I've found a non-sparse library to be slower (not when looking it up, but
when building a revision, probably because of the need to make all the
intermediate versions).  But maybe I should try it again.


        Stefan