Robert Stonehouse <rstonehouse@xxxxxxxxxxxxxx> writes: > I had a problem where I thought git bisect would be a good way forwards. > It didn't work as expected so I made myself a simpler test-case. > > featureA (which was a new build target) was broken at HEAD. It had been > developed on the featureA branch. After featureA was merged into master, > featureB (which had branched from master at the same point as featureA) was > merged with master. > > $ git log --graph --abbrev-commit --pretty=oneline > * b394c57... master4 > * 7e8d675... Merge branch 'featureB' > |\ > | * 8d87aee... featureB2 > | * c1a8450... featureB1 > * | 44c5601... master3 > * | 269602a... Merge branch 'featureA' > |\ \ > | * | 91b1bbb... featureA2 > | * | 0c15834... featureA1 > | |/ > * | 1ea4a0c... master2 > |/ > * 204f839... master1 > > Tag featureA1 was my good commit, and HEAD was the bad. > I was surprised that git bisect was asking me to test commits on the featureB > branch. I couldn't test the build target that was broken on branch featureB > because it wasn't present in the code at that point. That is what "git bisect skip [<rev>|<range>...]" is for." > Is there a way to do what I want (bisect all children of a commit)? Also in 'pu' there is refs/replace mechanism, which was intendend mainly to "repair" un-bisectable history... -- Jakub Narebski Poland ShadeHawk on #git -- 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