Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > Do we care in this case? I really don't know, but perhaps we can declare > "dedup" using the same facility we're using to wildcard-match keys, and > either make that optional or the default, e.g.: > > GIT_TRACE2_CONFIG_PARAMS='*:dedup,core.*:' > > I.e. to make it a list of <glob>[:<options>]. > > Maybe not worth the effort... I happen to think that the trace output is primarily for machine consumption (i.e. if you want to make it readable by humans, it is OK to require them to pre-process). How does this "duplicate output" come about? If it is because end-user configuration files have multiple entries that are either list-valued or relying on last-one-wins semantics, I suspect that it is better not to prematurely filter these at the trace generation side (which by definition is an opration that loses information). So, to me, it smells that the whole "dedup at the source" thing is not just not worth the effort but is misguided.
