Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: >> True but when fetching other references, tags relevant to the >> history being fetched by default should automatically follow, so the >> above explains why "fetch --tags" is not a useful thing to do daily. > > Maybe not necessary in many scenarios, but is it harmful for the common > case of cloning from and then periodically fetching from an upstream? There is no mention of "harmful"; I only said "not useful". And it comes primarily from knowing why "--tags" was introduced in the first place; I should have said "less useful than before, ever since we started to reliably auto-follow". The only "harmful" part is its interaction with "--prune", which your series nicely addresses. > ISTM that the result of the declarative --tags option > > we have all upstream tags > > is easier to reason about than the history-dependent tag-following behavior I'd say "we have all the relevant tags" and "we have all the tags the other side has" are equally valid things to wish for, depending who you are and how your project is organized, and one is not necessarily easy/useful than the other. In case it was unclear, I was not seriously advocating to deprecate/remove "--tags". > Regarding your first point: if it matters which of the duplicates is > chosen, then it can only matter because they differ in some other way > than their reference names, for example in their flags. So a robust way > of de-duping them (if it is possible) would be to compare the two > records and decide which one should take precedence based on this other > information rather than based on which one happened to come earlier in > the list. Then the list order would be immaterial and (for example) it > wouldn't be a problem to reorder the items. But that changes the behaviour to those who has cared to rely on the ordering. With the change to first collect and then sort unstably before deduping, the series already tells them not to rely on the order, and two of us tentatively agreed in this discussion that it is not likely to matter. If later this agreement turns out to be a mistake and there are people who *do* rely on the ordering, the only acceptable fix for them is by making sure we restore the "first one trumps" semantics, not by defining an alternative, arguably better, behaviour---that is not a regression fix. In any case, thanks for working on this topic. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html