[Gnu-arch-users] Re: Fast commits

[Stefan Monnier]

>>> I think the answer lies in redundancy: the current structure with
>>> {arch}/.../patch-log/patch-N files would work just as before.
>>> But we could also represent the same info with file with names
>>> {arch}/.../patch-log/patch-N-M.

>> Hmmm, that's clever....

> This might work out pretty cleanly.

> In essense, mkpatch and dopatch would:

> 1) maintain an index file of the virtual patch-log contents under
>    {arch}

Why?
It's not needed now and wouldn't been needed with my proposal either AFAICT.
Basically neither mkpatch nor dopatch would need to be changed...
weeellll:

The problems I can see with my approach are the following:
- Add patch-N-M to a tree that already has it: the new file's content
  should be the same, so it should be trivial to resolve the "conflict".
  This situation already exists, although my proposal might make it happen
  in a few new cases.
- remove patch-N (or patch-N-M) from a tree that doesn't have it.
  This situation also already exists, but now it gets a bit trickier
  because resolving the conflict can become less trivial since the tree
  might have patch-N "pruned" in patch-A-B, so we may have to take special
  steps to resolve such "remove an non-existing file" conflicts.
- remove patch-N (or patch-N-M) in a tree that does have it but that also
  has patch-A-B where N is between A and B.  Now, this is getting ugly
  because we have to figure out whether the removal of file patch-N
  is due to pruning (i.e. the patch is still present but in another file)
  or not in order to know whether we should also adjust patch-A-B (as well
  as any other patch file that contains N),

OK, well, still not completely trivial.


        Stefan