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

From: Kevin Bracey <kevin@bracey.fi>
Date: Apr 26, 2013, 19:18 UTC
Message-ID: <517AD304.6020807@bracey.fi>
In-Reply-To: <7v1u9y4gnq.fsf@alter.siamese.dyndns.org>

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

Show 6 quoted lines

> 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?

As it stands, it's one decoration per interesting merge commit that's processed by try_to_simplify_commit(), if simplify_merges is set. (Only simplify_merges needs the information at present - conceivably limit_to_ancestry could use it too). I don't know how to go about discarding the data, or when it could be done - I'm not clear enough on the wider sequencing machinery in revision.c yet.

I have a first draft of a set of patches, which will follow this message.

1/3 addresses the initial "get simplify_merges right", passing your test. That patch is written to make it easy to extend with the next two, which add a "never eliminate all our TREESAME parents" rule, and reinstate your reverted"eliminate irrelevant side branches". The error I spotted in that was that you weren't checking that you were eliminating root commits - with that fixed it seems sound to me.

I need to create a new test for patch 2, but this version passes the full test suite, including fixing the known failure in t6012, and it also gets the examples in the manual right. (I've extended the examples to include the irrelevant side branch - not sure this is worthwhile, as it's such an unusual case, and I think that section is confusing enough for newbies...)

Kevin