On Wed, May 30, 2018 at 11:20:40AM +0300, Kevin Bracey wrote: > On 30/05/2018 00:04, Jeff King wrote: > > > > Do we even need to do the parent rewriting here? By definition those > > parents aren't interesting, and we're TREESAME to whatever is in > > treesame_parents. So conceptually it seems like we just need a flag "I > > found a treesame parent", but we only convert that into a TREESAME flag > > if there are no relevant parents. > > I think it's necessary to make the rules consistent. To mark the commit as > TREESAME here when it's not TREESAME to all its parents would be > inconsistent with the definition of the TREESAME flag used everywhere else: > > * Original definition: "A commit is TREESAME if it is treesame to any > parent" > * d0af66 definition: "A commit is TREESAME if it is treesame to all parents" > * Current 4d8266 definition: "A commit is TREESAME if it is treesame to all > relevant parents; if no relevant parents then if it is treesame to all > (irrelevant) parents." > > The current problem is that the node is not marked TREESAME, but that's > consistent with the definition. I think we do have to rewrite the commit so > it is TREESAME as per the definition. Not flag it as TREESAME in violation > of it. If there are zero parents (neither relevant nor irrelevant), is it still TREESAME? I would say in theory yes. So what I was proposing would be to rewrite the parents to the empty set. But anyway, I agree with you that the first-treesame-parent strategy is not any more complex than the boolean, and is probably less likely to cause unintended headaches later on. What next here? It looks like we have a proposed solution. Do you want to try to work up a set of tests based on what you wrote earlier? I'd also love to hear from Junio as the expert in this area, but I think he's been a bit busy with maintainer stuff recently. So maybe I should just be patient. :) -Peff
