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
