noisy conflicting tags

[Kent Gibson]

Ian Clatworthy wrote:
>
> I suspect conflicting tags ought to still be a warning and therefore
> still output if --quiet is given. That doesn't impact this patch
> though.
>
It certainly doesn't impact the patch since conflicting tags are still
noisy.

However I don't think the term "conflicting", as applied to tags in a
merge, is that suitable.  It makes the user assume something needs to
be resolved before a merge can complete.  That is not the case for
tags.  The tags from source and destination are merged using an
algorithm that automatically resolves the conflict, either giving the
destination tags precedence, or the source if the --overwrite option
is used.
The fact that there are inconsistencies between the tagging on source
and dest is not something that needs to be dealt with immediately to
complete the push/pull/merge.  In fact it may not be possible to
correct immediately - if at all, depending on the ownership of the
branches involved.

What is lacking here is documentation that makes clear how tags are
propagated during push, pull and merge.  And some more feedback from
the push/pull/merge commands as to what they are doing with tags.  If
that were clearer, then the fact the tag merge is favouring the tags
in one branch over another is no longer an error - it is the expected
behaviour, and so should not be reported when --quiet is requested.
Such behaviour would also be consistent with the fact that
push/pull/merge still return 0 when conflicting tags are detected.
The alternative is to make those commands fail until the tags are
resolved (manually), and that doesn't seem workable to me.

I guess the other alternative is to version tags.  But do we want to
go there - I thought that had already been decided in favour of
non-versioned?

Cheers,
Kent.