Daniel Shahaf wrote on Thu, 19 Aug 2021 12:51 +00:00: > Daniel Sahlberg wrote on Wed, Aug 18, 2021 at 07:54:47 +0200: > > The larger question is "do we want it?".
> I think we should include it, because: > > - The API provides it. The CLI be to the API as the plain log output is > to the XML output. > > - It adds information: absence does not imply the value would be "true", > nor that it would be "false". > > In other words: Is it a property of r5 (which was filtered out, so > > it should be filtered out as well) It's definitely not a property of r5. It's quite possible for r5 to be forward merged into /foo in r6 and reverse merged into /bar in r8. It's even possible for r5 to be forward merged into /foo and reverse merged into /bar _in the same revision_. Thus, the "reverse-merge" attribute is, a property of the revision in which r5 was (forward or reverse) merged. > > or is it a property necessary to reconstruct the path to r4. Agree: The reverse-merge attribute on r5 is part of explaining how r4 is related to the target of the log (the path it was run against), so I think that too argues for keeping that attribute in the output. Is there an argument in favour of eliding that attribute that I'm overlooking? [honest question]
