Originally, we use "git rev-list -1 --parents" to get the list of parents, and therefore the 0th slot was the commit in question, the 1st slot was the 1st parent, and so forth. Commit 0a46941 switched this to use --pretty=format:%P, so that the menu-selection code could be easily used (which counts items starting from 0). However, we only use the menu code in the case of multiple parents. For a single parent, this introduced an off-by-one where we look just past the parent we want. This patch fixes it by explicitly selecting the 0th parent for the single parent case. Signed-off-by: Jeff King <peff@xxxxxxxx> --- This is an old bug, but I finally got a chance to track it down. There is a related buglet elsewhere in select_commit_parent. Now that we ask git to print only the parents, we will get no output at all for a parent-less commit. This will cause iobuf_read to return an error, and we will print "Failed to get parent information" instead of "The selected commit has no parents" (or "Path '%s' does not exist" if we are blaming the parent of a commit that introduced a file). AFAICT, fixing it would mean improving iobuf_read to differentiate "no output" from "there were errors". I'll leave that sort of infrastructure refactoring to you if you want to do it. The resulting bug is quite minor. tig.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/tig.c b/tig.c index 074e414..60932d4 100644 --- a/tig.c +++ b/tig.c @@ -4012,7 +4012,9 @@ select_commit_parent(const char *id, char rev[SIZEOF_REV], const char *path) return FALSE; } - if (parents > 1 && !open_commit_parent_menu(buf, &parents)) + if (parents == 1) + parents = 0; + else if (!open_commit_parent_menu(buf, &parents)) return FALSE; string_copy_rev(rev, &buf[41 * parents]); -- 1.7.1.248.gf52fc -- 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