[Gnu-arch-users] tale of the 'log-for-merge' problem

[Alexander Deruwe]

Hey all,

I recall a post I made back in the larch days about 'log-for-merge', and
some more recent ones as well.  I'm not going to search for references,
as everything will be explained here.


I started the aqs-carcontrol project for work back in the very early
days of larch in
address@hidden/aqs-carcontrol--trunk--0.7.

At patch-133 I tagged into a new archive:
address@hidden/carcontrol--aderuwe--0.7.

All my other branches for this project derive from this last one, and in
all other branches, 'tla log-for-merge' would return a whole battery of
incorrect patches.


Today, I decided to look at this problem again, this time with Robert
Collins lending a very helpful hand.
Turns out that the base-0 log in
address@hidden/carcontrol--aderuwe--0.7
contains only a handful 'New-patches:' where it should be a whole lot
more.
This causes 'merge-points/merges', 'log-for-merge' to see all patches not
listed as new patches, every commit again.

So, how come there's too few patches in the base-0 log you say?  Well,
let's check
address@hidden/aqs-carcontrol--trunk--0.7
to see where 'larch merge-points' works and where it doesn't.
And so I found at patch-128 a log that said:

Continuation-of: address@hidden/carcontrol--aderuwe--0.7--patch-128

Aiaiai!  How did that get there?  I tagged in a working branch?  No,
because that changeset also contains bonafide changes.  My only guess
(this is a changeset from 2002-12-12) is that I used (for whatever
reason) 'larch commit --continuation'.

>From this point on, 'larch merge-points' returned wrong data (starting
calculation only from patch-128), and since 'larch tag' uses
'larch merge-points', that's how the wrong base-0 log ended up in the
archive.

Note that tagging from
address@hidden/aqs-carcontrol--trunk--0.7
works fine with tla.  I guess it doesn't treat the 'Continuation-of'
header the same way.


Now that the cause of this is known, how would I go about fixing my
archive?  Also, recently I tagged this project into a tla-based archive,
and 'commit -L' has added faulty 'log-for-merge' output to a couple
patches; that would need to be fixed too. 

Glad this is solved at last! ;)

Alexander