Since c7d67ab running "tig" with no options has failed with the
error "tig: No revisions match the given arguments." This was due
to a change in how the arguments for the back-end git call was
being constructed. This change caused the blank field left in
place of "(encoding_arg)" when it is empty to not overwrite
"buf" which then caused the value in "buf" to be copied into
dst_argv twice. The resulting git command failed if there was no
available revision named "log" as shown in the trace.
>From the TIG_TRACE log:
git log log --no-color --pretty=raw --parents --parents --
fatal: bad revision 'log'
This fix works by properly and fully initializing "buf" before each use.
github issue # 167
Helped-by: Jonas Fonseca <fonseca@xxxxxxx>
Signed-off-by: Drew Northup <n1xim.email@xxxxxxxxx>
---
This should apply cleanly to the tig public master whether the
mkstemps() patch I wrote has been applied or not. (As of the time I
am sending this for review I haven't yet applied the latest fix to
my mkstemps() patch that has been submitted for git itself.)
This time, knowing for sure now that format->buf is not being used in
the extant code path for any other purpose, I went ahead and
initialized the whole thing to be sure that we don't find any other
ghosts hiding in that buffer between uses. Just initializing the
first byte fixes the near term problem but does not prevent the buffer
initialization issue that this bug highlighted from rising up again
later on.
tig.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tig.c b/tig.c
index ba9ba98..c65bc43 100644
--- a/tig.c
+++ b/tig.c
@@ -3104,8 +3104,12 @@ format_expand_arg(struct format_context *format, const char *name)
static bool
format_append_arg(struct format_context *format, const char ***dst_argv, const char *arg)
{
+ int i;
format->bufpos = 0;
+ for (i = 0; i < SIZEOF_STR; i++)
+ format->buf[i] = 0;
+
while (arg) {
char *next = strstr(arg, "%(");
int len = next ? next - arg : strlen(arg);
--
1.8.0
--
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