Jeff King <peff@xxxxxxxx> writes: > Could be a bad interaction between commits on nd/sparse and whatever was > done since it had branched. You can try rebasing nd/sparse and bisecting > a linearised version, like this: > > bad_merge=73d66323 > # pretend we are on nd/sparse > git checkout -b test $bad_merge^2 > # rebase onto what we merged onto > git rebase $bad_merge^1 That is a very good suggestion. You will get hit by a few conflicts during the rebase, but I managed to arrive at the same tree as $bad_merge after running the rebase procedure above. Just for Jonathan's convenience, the result is at: git://repo.or.cz/alt-git.git junk-linearized-nd-sparse-for-bisection I'll remove this after a few days. > # now bisect. what we have now is presumably > # bad (though you should probably double check) > # and from the previous bisect we know that > # everything pre-merge is good > git bisect start > git bisect good $bad_merge^1 > git bisect bad It would be interesting to hear the result of the test in the particular repository Jonathan is seeing the problem with. The issue didn't reproduce for me, either but I only tried "having a staged change" case without any more detailed set-up. -- 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