Re: [RFC/PATCH] Make --full-history consider more merges

Kevin Bracey [off-list ref] writes:

On 25/04/2013 19:51, Junio C Hamano wrote:

quoted

Kevin Bracey [off-list ref] writes:

quoted

Thanks for the test addition. Maybe we will be able to satisfy your
greed in this series. There could be more worth doing here, and I
think getting TREESAME precise is key.

It is perfectly fine to do things one step at a time.  Let's get
the --full-history change into a good shape first and worry about
the more complex case after we are done.

So do you see the rerun of try_to_simplify_commit() as acceptable? I'm
really not happy with it - it was fine for an initial
proof-of-concept, but it's an obvious waste of CPU cycles to recompute
something we already figured out, and I'm uncomfortable with the fact
that the function potentially does more than just compute TREESAME; by
inspection it seems safe given the known context inside
simplify_merges(), but it feels like something waiting to trip us
up.

True.

The latter could be dealt with by breaking
try_to_simplify_commit() up, but that feels like a diversion. I'd
rather just get on and make this first patch store and use the
per-parent-treesame flags if feasible.

OK.  We have survived with this corner case glitch for more than 6
years, so a fix is not ultra-urgent.  Let's try to see if we can get
it right.

How many decorations are we talking about here?  One for each merge
commit in the entire history?  Do we have a cue that can tell us
when we are really done with a commit that lets us discard the
associated data as we go on digging, keeping the size of our working
set somewhat bounded, perhaps proportional to the number of commits
in our rev_info->commits queue?