Weird behavior of git rev-parse

Weird behavior of git rev-parse

[Yakup Akbay]

Hi,

instead of `git rev-list -2 HEAD` I've tried `git rev-parse -2 HEAD` 
just to see the effect of -N in rev-parse, but I've got this output:

    -2
    0294cdd1e2c5535f5b87eff4a1aff3390e03af39

Then I've tried

    $ git rev-parse -'hi, this is a test!'

the output is:

    -hi, this is a test!

Is this an expected behavior?


Another questions is, usage is printed if you omit the commit id in git 
rev-list (E.g. `git rev-list -2`). Is there a reason why HEAD is not 
taken as the default?

Regards,
Yakup

Re: Weird behavior of git rev-parse

[Santi Béjar]

2009/7/14 Yakup Akbay <yakbay@ubicom.com>:
> Hi,
>
> instead of `git rev-list -2 HEAD` I've tried `git rev-parse -2 HEAD` just to
> see the effect of -N in rev-parse, but I've got this output:
>
>   -2
>   0294cdd1e2c5535f5b87eff4a1aff3390e03af39
>
> Then I've tried
>
>   $ git rev-parse -'hi, this is a test!'
>
> the output is:
>
>   -hi, this is a test!
>
> Is this an expected behavior?

There is no "-N" flag to "git rev-parse", neither "-'hi, this is a
test!'". The purpuse of git rev-parse is for porcelainish commands to
parse their argument, as the man page says:

git-rev-parse - Pick out and massage parameters

Many git porcelainish commands take mixture of flags
(i.e. parameters that begin with a dash '-') and parameters
meant for the underlying 'git-rev-list' command they use internally
and flags and parameters for the other commands they use
downstream of 'git-rev-list'.  This command is used to
distinguish between them.

>
>
> Another questions is, usage is printed if you omit the commit id in git
> rev-list (E.g. `git rev-list -2`). Is there a reason why HEAD is not taken
> as the default?

You can say what is the default with --default <arg>.

HTH,
Santi

Re: Weird behavior of git rev-parse

[Junio C Hamano]

Yakup Akbay <yakbay@ubicom.com> writes:

> Then I've tried
>
>    $ git rev-parse -'hi, this is a test!'
>
> the output is:
>
>    -hi, this is a test!
>
> Is this an expected behavior?

Absolutely.  rev-parse was originally written as a way for Porcelain
scripts to sift parameters into four different categories.

 * options and non-options (that's two)

 * args meant for rev-list and others (that's another two)

Multiplying two x two gives you four combinations.

Because you are not giving options like --revs-only, --no-revs, --flags,
nor --no-flags, rev-parse outputs everything.  You can try these:

$ git rev-parse --no-flags -'Hi'
$ git rev-parse --no-revs HEAD
$ git rev-parse --flags --no-revs -Hi HEAD

> Another questions is, usage is printed if you omit the commit id in
> git rev-list (E.g. `git rev-list -2`). Is there a reason why HEAD is
> not taken as the default?

The reason is because that is the way it has been, that is the way it is,
and changing it will break existing behaviour and scripts.  In other
words, it is a historical accident without any deep logic.

Besides, "git rev-list" is a plumbing and didn't necessarily want a
user-friendliness niceties such as "defaulting to X when nothing is
given".

Re: Weird behavior of git rev-parse

[Yakup Akbay]

Junio C Hamano wrote:
> Yakup Akbay <yakbay@ubicom.com> writes:
>
>   
>> Then I've tried
>>
>>    $ git rev-parse -'hi, this is a test!'
>>
>> the output is:
>>
>>    -hi, this is a test!
>>
>> Is this an expected behavior?
>>     
>
> Absolutely.  rev-parse was originally written as a way for Porcelain
> scripts to sift parameters into four different categories.
>
>  * options and non-options (that's two)
>
>  * args meant for rev-list and others (that's another two)
>
> Multiplying two x two gives you four combinations.
>
> Because you are not giving options like --revs-only, --no-revs, --flags,
> nor --no-flags, rev-parse outputs everything.  You can try these:
>
> $ git rev-parse --no-flags -'Hi'
> $ git rev-parse --no-revs HEAD
> $ git rev-parse --flags --no-revs -Hi HEAD
>   
Got it!

>> Another questions is, usage is printed if you omit the commit id in
>> git rev-list (E.g. `git rev-list -2`). Is there a reason why HEAD is
>> not taken as the default?
>>     
>
> The reason is because that is the way it has been, that is the way it is,
> and changing it will break existing behaviour and scripts.  In other
> words, it is a historical accident without any deep logic.
>
> Besides, "git rev-list" is a plumbing and didn't necessarily want a
> user-friendliness niceties such as "defaulting to X when nothing is
> given".
>
>   
Makes sense, thanks!

Yakup

Re: Weird behavior of git rev-parse

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:

> Yakup Akbay <yakbay@ubicom.com> writes:
> 
> > Then I've tried
> >
> >    $ git rev-parse -'hi, this is a test!'
> >
> > the output is:
> >
> >    -hi, this is a test!
> >
> > Is this an expected behavior?
> 
> Absolutely.  rev-parse was originally written as a way for Porcelain
> scripts to sift parameters into four different categories.
> 
>  * options and non-options (that's two)
> 
>  * args meant for rev-list and others (that's another two)
> 
> Multiplying two x two gives you four combinations.
> 
> Because you are not giving options like --revs-only, --no-revs, --flags,
> nor --no-flags, rev-parse outputs everything.

git-rev-parse can also be used to bring parseopt to shell scripts.

-- 
Jakub Narebski
Poland
ShadeHawk on #git