rev-parse, unknown arguments and extended sha1's

rev-parse, unknown arguments and extended sha1's

[Sven Verdoolaege]

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

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

[Linus Torvalds]

On Fri, 24 Jun 2005, Sven Verdoolaege wrote:
>
> 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

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

[Sven Verdoolaege]

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

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

[Linus Torvalds]

On Fri, 24 Jun 2005, Sven Verdoolaege wrote:
>
> 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

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

[Linus Torvalds]

On Fri, 24 Jun 2005, Linus Torvalds wrote:
> 
> 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