Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal

[Aaron Bentley]

Matthew Dempsky wrote:
> For what it's worth, patch-7 was generated by star-merging
> address@hidden/tla--get-changeset-fix--1.3.  Presumably under
> the modifications to the process Tom has recommended, you would be
> able to additionally know that.  (Right now that's not evident,
> however.)
>
> I expect the necessary changes can be made by simply commiting a patch
> to add =merges with all the versions I've merged patches from

If =merges lists address@hidden/tlasrc--devel--0.2, 
I'll be screwed.

If patch-7 added address@hidden/tla--get-changeset-fix--1.3 to 
=merges, I could:
1. download the changeset for patch-7,
2. find out that it added address@hidden/tla--get-changeset-fix--1.3
3. download the patchlogs for 
address@hidden/tla--get-changeset-fix--1.3
4. determine that they merged patches that are already present in the tree.

It would be better if =merged listed the actual revisions merged.

It would be *much* better if there was a header in the patch-7 that 
listed the revisions that had been merged, because then we could just 
download the patchlog instead of downloading and parsing the changeset.

So it's a crying shame that we have such a header already, with tool 
support and everything, but the header's been subverted.

Now, it's too late to add anything to =merges.  It's not reasonable for 
me to consult a later revision of tla--devo--1.3 to determine whether to 
replay patch-7.

> , or if
> it's necessary to know in the individual patches I can undo all the
> work I've done right now and remerge them.

That would be great.  I'm sorry that you're stuck in the middle of this.

Aaron