Christian Couder [off-list ref] writes:
quoted
If someone creates a "git decompose-octopus <commit>" command then ...
I am afraid that misses the entire point of my discussion.
Such a decomposed octopus would _only_ be necessary during bisection, only
when the user chooses to test two tips at once (instead of testing one by
one), _and_ only its tree is needed for that purpose. In other words, we
should be able to do this _without_ creating an extra commit, let alone
replace mechanism.
On Thu, 25 Jun 2009, Junio C Hamano wrote:
Such a decomposed octopus would _only_ be necessary during bisection, only
when the user chooses to test two tips at once (instead of testing one by
one), _and_ only its tree is needed for that purpose. In other words, we
should be able to do this _without_ creating an extra commit, let alone
replace mechanism.
Keep in mind, though, that realistically, I don't think we've ever seen
any bisection attempts that end at an octopus.
Sure, I suspect that being really clever about decomposing an octopus
merge might allow us to bisect things _faster_ to one of the branches
involved in the merge, but the amount of smarts to do that just for that
reason seems pretty outlandish.
And if we ever do end up with an actual bug being bisected to the octopus
merge itself, at that point I don't think it's unreasonable to take the
same approach we do with any normal merge: just try to figure out what the
conflict is all about (clearly it's not a data conflict, since the
octopus wouldn't have succeeded in that case, but subtle merge errors can
be due to two branches each introducing their own assumptions without
actually ever clashing on a source file level).
With regular merges, if you really don't see what the conceptual conflict
is, you could try to do a temporary rebase to try to figure it out, and I
suspect that that is what you'd want to do with an octopus merge too -
rather than try to decompose the octopus merge into multiple simpler
merges, you'd like to try to linearize history and then re-do the
bisection attempt on that totally modified/simplified history.
Linus
On Friday 26 June 2009, Junio C Hamano wrote:
Christian Couder [off-list ref] writes:
quoted
quoted
If someone creates a "git decompose-octopus <commit>" command then ...
I am afraid that misses the entire point of my discussion.
Such a decomposed octopus would _only_ be necessary during bisection,
only when the user chooses to test two tips at once (instead of testing
one by one), _and_ only its tree is needed for that purpose. In other
words, we should be able to do this _without_ creating an extra commit,
let alone replace mechanism.
But suppose the result from the bisection tells that M1 is the first bad
commit, then the user will need to look at M1, and perhaps check it out or
use it in other ways after the bisection is finished. So why shouldn't it
be a real commit?
It's not like a few more commits are a big problem as they will be reclaimed
by garbage collection anyway if the replace ref is deleted.
Best regards,
Christian.