Counterintuitive tag behaviour (broken design?)

[Alexis S. L. Carvalho]

Thus spake Matt Mackall:
> This logic is still hard to get right and there will still need to be
> tie-breakers based on what's 'tip-most' to remove ambiguity.

We could try something different from "tip-most" to remove ambiguity.
The last time this came up on IRC, there were at least 2 possible
suggestions:

- instead of changeset closest to the changelog tip, use file revision
  closest to the the .hgtags revlog tip

- follow the linkrev from the .hgtags revision and sort by the changeset
  date

The first one should avoid changes in the set of tags by a commit that
doesn't touch .hgtags, but you can still easily build 2 copies of the
same repo that have different sets of tags.

The second one also avoids changes in the set of tags by a commit that
doesn't touch .hgtags and makes it much harder (but still possible) to
have 2 copies of the same repo with different sets of tags.

I think sorting by date is very seductive, but it can also open a
different can of worms.

Even with these changes looking at the order of the lines in .hgtags
would still be useful.

Alexis