[tig PATCH] fix off-by-one on parent selection

[Jeff King <peff@peff.net>]

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@peff.net>
---
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