threads / discuss / 1018

rev-parse, unknown arguments and extended sha1's

Subject: rev-parse, unknown arguments and extended sha1's

## tl;dr

5 messages between Jun 24, 2005 and Jun 24, 2005.

replies: 4people: 2as markdown or json

Sven Verdoolaege· Jun 24, 2005, 12:24 UTC · lore

Is git-rev-parse supposed to echo arguments it doesn't understand ? It currently does, but git-checkout-script seems to think it doesn't:

                rev=$(git-rev-parse "$arg")   
                if [ -z "$rev" ]; then
                        echo "unknown flag $arg"
                        exit 1
                fi

Also, is there any reason why the extended sha1 notation is restricted to the scripts and not used in the actual plumbing ?

skimo
Linus Torvalds· Jun 24, 2005, 16:09 UTC · re: Sven Verdoolaege · lore

Re: rev-parse, unknown arguments and extended sha1's

On Fri, 24 Jun 2005, Sven Verdoolaege wrote:
Show 9 quoted lines
>
> Is git-rev-parse supposed to echo arguments it doesn't understand ?
> It currently does, but git-checkout-script seems to think it doesn't:
> 
>                 rev=$(git-rev-parse "$arg")   
>                 if [ -z "$rev" ]; then
>                         echo "unknown flag $arg"
>                         exit 1
>                 fi

Argh, there's a "--revs-only" thing that I was planning to use there, some remnant of an ealy plan (unimplemented) to use that to determine if it is a filename to be checked out, or a revision.

But then I never got around to do the "specify individual filenames" part of "git checkout".

Anyway, add the --revs-only, and the test against empty should make a bit more sense. In fact, it _should_ test that it's a SHA1 (and not a rev argument), but I couldn't come up with a good way to test that in shell.

		Linus
Sven Verdoolaege· Jun 24, 2005, 16:17 UTC · re: Linus Torvalds · lore

Re: rev-parse, unknown arguments and extended sha1's

On Fri, Jun 24, 2005 at 09:09:23AM -0700, Linus Torvalds wrote:
> Anyway, add the --revs-only, and the test against empty should make a bit 
> more sense. In fact, it _should_ test that it's a SHA1 (and not a rev 
> argument), but I couldn't come up with a good way to test that in shell.
> 
This is what I use:
rev2=`echo $rev | sed -e 's/[^0-9a-f]//'`
rev3=`echo $rev2 | sed -e 's/........................................//'`
if test "x$rev3" = "x" -a "x$rev" = "x$rev2"; then
	echo "valid SHA1"
fi
skimo
Linus Torvalds· Jun 24, 2005, 16:43 UTC · re: Sven Verdoolaege · lore

Re: rev-parse, unknown arguments and extended sha1's

On Fri, 24 Jun 2005, Sven Verdoolaege wrote:
Show 8 quoted lines
>
> This is what I use:
> 
> rev2=`echo $rev | sed -e 's/[^0-9a-f]//'`
> rev3=`echo $rev2 | sed -e 's/........................................//'`
> if test "x$rev3" = "x" -a "x$rev" = "x$rev2"; then
> 	echo "valid SHA1"
> fi
Oooh. UGGHLEE.
This is one reason I don't do much shell.

Anyway, I think I'll make git-rev-parse have some option to "error out if the result is anything but a single revision number", since this is really the only reason for git-rev-parse in the first place: to make readable scripts.

		Linus
Linus Torvalds· Jun 24, 2005, 17:32 UTC · re: Linus Torvalds · lore

Re: rev-parse, unknown arguments and extended sha1's

On Fri, 24 Jun 2005, Linus Torvalds wrote:
Show 5 quoted lines
> 
> Anyway, I think I'll make git-rev-parse have some option to "error out if 
> the result is anything but a single revision number", since this is really 
> the only reason for git-rev-parse in the first place: to make readable 
> scripts.
How about something like
	rev=$(git-rev-parse --default HEAD --revs-only --verify "$@") || exit 1
which now should work correctly.

In particular, the "--default" field is now expanded properly as a revision, instead of just output raw, so the "HEAD" actually gets translated into its SHA1 representation (and this also means that you can now use SHA1 expressions in "default", ie you don't need to do two git-rev-parse phases to do "--default HEAD^" etc).

The "--verify" thing then checks that the end result isn't a revision argument (ie "--max-age=.." isn't accepted), and that there's exactly one revision in the result (ie no ranges or multiple revisions some other way).

So now you shouldn't need to check the result any more. You know that if it worked, "rev" will be a nice SHA1 (of course, it might still be an _invalid_ SHA1, that's a different issue. But it's at least syntactically ok)

		Linus

← back to recent threads