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