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

2013-04-26 Thread Kevin Bracey
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

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

2013-04-25 Thread Kevin Bracey
On 25/04/2013 04:59, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: So, given all that, revised patch below: I tried to squeeze the minimum test I sent $gmane/220919 to the test suite. I think the do not use --parents option for this test switch needs to be cleaned up a bit

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

2013-04-25 Thread Junio C Hamano
Kevin Bracey ke...@bracey.fi writes: On 25/04/2013 04:59, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: So, given all that, revised patch below: I tried to squeeze the minimum test I sent $gmane/220919 to the test suite. I think the do not use --parents option for this

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

2013-04-25 Thread Kevin Bracey
On 25/04/2013 19:51, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: 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

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

2013-04-25 Thread Junio C Hamano
Kevin Bracey ke...@bracey.fi writes: On 25/04/2013 19:51, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: 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.

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

2013-04-24 Thread Junio C Hamano
Kevin Bracey ke...@bracey.fi writes: If simplify_history is set, and we do want ancestry, then it doesn't matter about the TREESAME definition because it shows all merges, regardless of the TREESAME flag. Thus adding --parents to the above command means it can find it, but only because it

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

2013-04-24 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: So, given all that, revised patch below: I tried to squeeze the minimum test I sent $gmane/220919 to the test suite. I think the do not use --parents option for this test switch needs to be cleaned up a bit more, but it fails without your patch and does

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

2013-04-23 Thread Kevin Bracey
On 22/04/2013 22:49, Junio C Hamano wrote: So in addition to have some change and there is no same parent case, under _some_ condition we avoid marking a merge not worth showing (i.e. TREESAME) if there is any change. And the condition is !simplify_history and !simplify_merges, which would

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

2013-04-22 Thread Kevin Bracey
History simplification previously always treated merges as TREESAME if they were TREESAME to any parent. While the desired default behaviour, this could be extremely unhelpful when searching detailed history, and could not be overridden. For example, if a merge had ignored a change, as if by -s

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

2013-04-22 Thread Junio C Hamano
Kevin Bracey ke...@bracey.fi writes: diff --git a/revision.c b/revision.c index eb98128..96fe3f5 100644 --- a/revision.c +++ b/revision.c @@ -516,8 +516,14 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit) } die(bad tree