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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html