为什么'git bisect'分支没有意识到？

Question

我试图找到一个错误的来源,这个错误是自从过去一天在一个名为feature-x的长寿命分支(将在很久以后发布)中提交以来出现的.

但是有一个错误.我找到了我不希望从我的脚本中可能已经在任何提交中引入的行为,特别是因为master的特性在feature-x中被大量使用,但是对于Master本身而言则较少.

要测试此行为,我必须运行我的脚本dependent.pl.但当bisect跳过代码的一半时,我的脚本在Master上不存在,因此无法测试.

我相信这是因为bisect将你拉到无头状态,但在这种情况下我真的想要处于这个其他历史/变化集的背景下,而不是漂浮在以太.

在任何人跳起来之前你做错了蜂鸣器之前,我们的团队喜欢在这些情况下合并分支,因为这个比喻适用于这种情况,而不是重组.

我将通过创建一个样本回购来演示这个:

git init

echo 'sub f { print $_; }' > main.pl
git add .
git commit -a -m "inital commit"

git branch feature-x
git checkout feature-x
echo 'main::f(1)' > dependent.pl
git add .
git commit -a -m "Starting work on feature X"
git tag dev-1.0

git checkout master
echo "sub f { return 1; }" > main.pl
git commit -a -m "sub f { return 1; }"
echo "sub f { return 2; }" > main.pl
git commit -a -m "sub f { return 2; }"
echo "sub f { return 3; }" > main.pl
git commit -a -m "sub f { return 3; }"

git tag release-1.0

git checkout feature-x
git merge master

echo 'print main::f();' > dependent.pl
git commit -a -m "Updating call to f"

所以现在你得到一个看起来像这样的回购:

o Updating call to f ( Head of branch 'feature-x' )
o Merge branch master onto feature-x
|\
| o sub f { return 3; } (TAG release-1.0) ( Head of branch 'master' )
| o sub f { return 2; }
| o sub f { return 1; }
o | Starting work on feature X ( TAG 'dev-1.0' )
 \|
  o initial commit

所以我运行命令git bisect start feature-x dev-1.0期望我能找到什么破坏了我在dependent.pl中的代码,我最终提交'sub f {return 2}'而没有我对feature-x的更改历史记录(即如果我运行ls,所有我看到的是main.pl和dependent.pl缺失).

这使我处于一个不稳定的状态.我不知道当前的提交是否破坏了我的工作,也不能说对master的提交打破了它,所以我不能说这个提交是好还是坏.

我怎样才能测试当前分支的哪些内容？

Answer 1

这里的问题是git bisect 是分支感知的.当你告诉它"依赖"是好的并且"测试"是坏的,并且存在合并提交之间的变化之一时,它知道为了找出问题的引入位置,它将不得不看提交a,b和c - 否则,它能够告诉你它是否在合并提交时被破坏了.

听起来你期望的是测试commit b与来自其他分支的更改的组合,这是在任何提交中都不存在的内容,并且git bisect只允许你测试提交!为了测试那些内容,你必须做一系列的测试合并 - 检查b,合并依赖,让你测试,然后签出一个或c,合并依赖,让你再次测试.git merge --no-commit dependent一旦它离开你在提交b,你可以很容易地做,然后git reset --hard在运行之前完成测试git bisect good/bad.

否则,如果我误解了你希望它不测试合并分支上的任何提交,并且只测试合并提交本身(你不关心a,b或c中的哪一个打破它),只需告诉它一切在合并的分支上是好的.如果你知道a,b和c与它无关,那就更好了.然后你知道甚至没有测试他们是好的!

但是你不能指望的一件事就是让git完全忽略提交a,b和c.它绝对无法知道他们的更改是否与您的"错误"相关,并且他们的更改是您的好的和坏的提交之间的差异的一部分.