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

[Kevin Bracey <kevin@bracey.fi>]

On 25/04/2013 21:19, Junio C Hamano wrote:
> 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