Re: Weird revision walk behaviour

[Jeff King <peff@peff.net>]

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