git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* git-blame: handling of revisions and filenames
@ 2006-11-15 21:52 Alex Riesen
  2006-11-29 18:29 ` Junio C Hamano
  0 siblings, 1 reply; 2+ messages in thread
From: Alex Riesen @ 2006-11-15 21:52 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

I noticed that there is no safe way to give a revision to git-blame:
it can always be interpreted as an existing file:
 - "git blame rev -- file.txt" can fail if "rev" is a file
 - "git blame rev^0 -- file.txt" can file there is a "rev^0" file
   (happens if you type too fast with a tool not designed for keyboard)
 - "git blame file.txt rev" is ambiguos too, for the same reasons.

I did the simple patch (below) to resolve at least the very first one,
just because that is how git-rev-list does it.
But if all forms of git-blame command line are expected to live, a
more serious surgery of the argv[] handling code needed.
And I afraid the patch has a small chance of crashing: I don't check
if there is enough space in argv (don't actually even know how to),
so Junio, please do not apply it (it passes blame tests, though).
I also suspect git-blame is not the only command using revision
machinery which has the same problem, so this message is more like a
discussion starter.

diff --git a/builtin-blame.c b/builtin-blame.c
index 066dee7..83c8905 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1787,6 +1787,7 @@ int cmd_blame(int argc, const char **arg
        /* Now we got rev and path.  We do not want the path pruning
         * but we may want "bottom" processing.
         */
+       argv[unk++] = "--";
        argv[unk] = NULL;
 
        init_revisions(&revs, NULL);

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: git-blame: handling of revisions and filenames
  2006-11-15 21:52 git-blame: handling of revisions and filenames Alex Riesen
@ 2006-11-29 18:29 ` Junio C Hamano
  0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2006-11-29 18:29 UTC (permalink / raw)
  To: Alex Riesen; +Cc: git

fork0@t-online.de (Alex Riesen) writes:

> And I afraid the patch has a small chance of crashing: I don't check
> if there is enough space in argv (don't actually even know how to),

Actually this is a safe thing to do because we already know (and
removed) the "path" argument from the command line at that
point.  If the original command line did not have "path" we have
already rejected it.  So unk at that point never exceeds argc.

> diff --git a/builtin-blame.c b/builtin-blame.c
> index 066dee7..83c8905 100644
> --- a/builtin-blame.c
> +++ b/builtin-blame.c
> @@ -1787,6 +1787,7 @@ int cmd_blame(int argc, const char **arg
>         /* Now we got rev and path.  We do not want the path pruning
>          * but we may want "bottom" processing.
>          */
> +       argv[unk++] = "--";
>         argv[unk] = NULL;
>  
>         init_revisions(&revs, NULL);

Thanks.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2006-11-29 18:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-15 21:52 git-blame: handling of revisions and filenames Alex Riesen
2006-11-29 18:29 ` Junio C Hamano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).