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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kevin Bracey <kevin@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]