Skip to content

Can't push after topic change right before publication

(will be reconfirmed by a unit test in py-heptapod)

To reproduce:

  • make a topic (one changeset, let's call it A is enough)
  • push
  • change (or clear) the topic on the head changeset of the topic, thus obsoleting A by B
  • publish B
  • push

Reason: the piece of logic that examines what to do of published topics will first see that A is obsolete and jump immediately to B. Then it will look for the latest descendant (inclusive) of B bearing the original topic:

Example, in the aftermath of pypy/pypy!721:

lib/python2.7/site-packages/hgext3rd/heptapod/git.py", line 598, in latest_topic_descendant
   ctx.hex(), topic))
LookupError: Can't find public descendants of '53b86a37acef955d060e59535d8bde676933c1d1' in topic 'BO-fix-doc-source-links'

Indeed 53b86a37acef955d060e59535d8bde676933c1d1 is public, obsoletes the original topic head to removes the topic information. That broke subsequent pushes (signaled by @rlamy)

This latest_topic_descendant method is meant for Merge Requests, so that the MR can display all relevant changesets, even if some are added in the same push as the publication.

Since its first incarnation, we've left a hard error here to avoid putting garbage in there. Also at the time, it was harder to clean a bad mirrorring (likely prone to produce hard errors as well) than it is today. It's probably now safer if no descendant is found to simply leave it as it is (B in our example).

It would be wrong to follow on in case of change of topic.

Edited by Georges Racinet
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information