Le 11/03/2020 à 12:33, Mathieu Lirzin a écrit :
Yes things seems to happen not magically but by putting earplugs on and
going ahead, which is certainly more effective but IMO not acceptable
when working within a community.
I'm not sure to who it's destined, so I'll not take it for me :)
BTW, a question for you: do you think not having a linear commit
history would have an impact on Bisect. I don't think so, just asking
in case you have an experience with that.
‘git bisect’ handles non-linear history nicely but it achieves this with
a more complex algorithm than basic binary search [1][2].
The difficulty is when a commit identified as introducing the regression
is a merge commit because it requires analysing each branch up to their
common ancestor.
Thanks, did not think about that.
The major issue is more social, because once people adopts the practice
of merging branches without rebasing and cleaning that branch first,
since contributors often branch from another development branch, this
will eventually lead to have the same commit present multiple times but
with different hashes.
Mmm, that's bad indeed.
The simple solution to prevent this is to get into the habit of
linearizing history, meaning always rebasing and clean history before
merging into trunk.
I guess the GH merge button option "Rebase and merge" is what we are looking to
enforce with the request to Infra, right?
--
Jacques Le Roux
400E Chemin de la Mouline
34560 Poussan
04 67 51 19 38
06 11 79 50 28
