Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [RFC/PATCH 2/3] simplify-merges: never remove all TREESAME parents

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:57:03

Kevin Bracey [off-list ref] writes:
quoted
Could you explain here a bit more the reason why we do not want to
remove them and why "-s ours" is so significant that it deserves to
be singled out?  And why randomly picking one that is redundant
(because it is an ancestor of some other parent) is an improvement?
I feel it's consistent with the default non-full-history
behaviour. The parent that we choose not to remove is the  same one
that the default log with "simplify_history==1" would have followed:
the first parent we are TREESAME to. Or at least that's the intent. So
this parent would normally be singled out, and it's not an arbitrary
(or "random") choice.

It feels wrong to me that --full-history --simplify-merges could
produce a disjoint history from the default.
Finally ;-)  That "avoid creating a disjoint history" is the "why we
do not want to remove them" I wanted to see in the same comment.
But this patch as it stands was an "easy" change to make with clearly
limited scope and relatively little risk - I specifically wanted just
to include our default "simple" parent.
Yeah, I think it all makes sense.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help