:thumbsup:

The condition does not match the text. If dsttag is non-null here, then the destination is not a new tag.
In any case, cloning builds should not require --force so routinely.

I really don't like that this change requires --force.

I think that the important case for ordering here is the new tag case. That part of the fix is trivial.

For the existing tag case, I think I'd almost rather not go to the lengths that this patch does, at least for now. We should probably add missing builds in the correct order, but I'm not sure how importan #916 is for the existing tag case.

If we do want to handle this for the existing tag case, then the correct way is to compare the orders, and determine which combinations of tagging and untagging of builds is required to correct it (rather than relying on force).

That is significantly more complicated that the new tag case, so maybe we should defer that to a later PR.

For the existing tag case, I think I'd almost rather not go to the lengths that this patch does, at least for now. We should probably add missing builds in the correct order, but I'm not sure how importan #916 is for the existing tag case.

--force tagging is required when the srctag is older than dsttag or we want to keep the order completely same as srctag. I think it's possible but obviously rare

If we do want to handle this for the existing tag case, then the correct way is to compare the orders, and determine which combinations of tagging and untagging of builds is required to correct it (rather than relying on force).

That is significantly more complicated that the new tag case, so maybe we should defer that to a later PR.

it makes sense, I'll just reverse the order for both new tag and existing tag

@tkopecek @mikem please review again

srclblds and dstlblds seem to stand for "source latest builds" and "destination latest builds" respectively. However:

• srclblds is only latest if --latest-only is given, whereas dstlblds is always latest
• these two values, though so similarly named, are generated quite differently

The fact that dstlblds is always the latest builds for the tag causes this command it get things wrong:

• adding nvrs to baddlist even though they are in the dst tag
• failing to add nvrs to bdellist because they are not latest

To be fair, this is not the fault of the current patch, so maybe we can defer fixing this.

Commit 346fb028 fixes this pull-request

Commit 346fb028 fixes this pull-request

Sorry, not actually merged yet

I guess we can merge this as-is. I'll file another issue for the poor behavior with existing tags

Commit 524ce543 fixes this pull-request

Filed #960 for the other bits