summaryrefslogtreecommitdiff
path: root/builtin-diff.c
diff options
context:
space:
mode:
authorChristian Couder <chriscool@tuxfamily.org>2008-08-22 03:52:22 (GMT)
committerJunio C Hamano <gitster@pobox.com>2008-08-28 01:08:04 (GMT)
commitf821d0892173e4e46a71fef4d06995f7a81c9296 (patch)
treea3bf9d92831f2d611a863617b785f2dda273b107 /builtin-diff.c
parenta1184d85e8752658f02746982822f43f32316803 (diff)
downloadgit-f821d0892173e4e46a71fef4d06995f7a81c9296.zip
git-f821d0892173e4e46a71fef4d06995f7a81c9296.tar.gz
git-f821d0892173e4e46a71fef4d06995f7a81c9296.tar.bz2
bisect: test merge base if good rev is not an ancestor of bad rev
Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin-diff.c')
0 files changed, 0 insertions, 0 deletions