Fwiw, look very a sound idea for me.
Best
2013/3/30, Junio C Hamano :
> Junio C Hamano writes:
>
>> What we may want is another type peeling operator, ^{object}.
>> that makes sure it is an object, like this:
>>
>> rev-parse --verify 572a535454612a046e7dd7404dcca94d6243c788^{object}
>>
>> It
On 03/30/2013 08:05 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> What we may want is another type peeling operator, ^{object}.
>> that makes sure it is an object, like this:
>>
>> rev-parse --verify 572a535454612a046e7dd7404dcca94d6243c788^{object}
>>
>> It asks "I have this 40-hex
Junio C Hamano writes:
> What we may want is another type peeling operator, ^{object}.
> that makes sure it is an object, like this:
>
> rev-parse --verify 572a535454612a046e7dd7404dcca94d6243c788^{object}
>
> It asks "I have this 40-hex; I want an object out of it", just like
> frotz^{tree}
Michael Haggerty writes:
> On 03/30/2013 05:09 AM, Junio C Hamano wrote:
>> So why not verify arguments while making sure of their type early
>> with 'rev-parse --verify "$userinput^{desiredtype}"?
>
> Yes, that's a better solution in almost all cases. Thanks for the tip.
>
> (It doesn't change
On 03/30/2013 05:09 AM, Junio C Hamano wrote:
> So why not verify arguments while making sure of their type early
> with 'rev-parse --verify "$userinput^{desiredtype}"?
Yes, that's a better solution in almost all cases. Thanks for the tip.
(It doesn't change my opinion that the documentation for
Junio C Hamano writes:
>> 3. Verifying arguments at one spot centralizes error-checking at the
>> start of a script and eliminates one reason for random git commands to
>> fail later (when error recovery is perhaps more difficult).
>
> Not necessarily, unless your script is a very narrow corner c
Michael Haggerty writes:
> 1. An SHA1 is a canonical representation of the argument, useful for
> example as the key in a hash map for for looking for the presence of a
> commit in a rev-list output.
>
> 2. An SHA1 is persistent. For example, I use them when caching
> benchmark results across ve
On 03/28/2013 05:52 PM, Junio C Hamano wrote:
> You could force rev-parse to resolve the input to an existing
> object, with something like this:
>
> git rev-parse --verify "$ARG^{}"
>
> It will unwrap a tag, so the output may end up pointing at a object
> that is different from $ARG in suc
Jeff King writes:
> On Thu, Mar 28, 2013 at 04:34:19PM +0100, Michael Haggerty wrote:
>
>> Is there a simple way to verify an object name more strictly and convert
>> it to an SHA1? I can only think of solutions that require two commands,
>> like
>>
>> git cat-file -e $ARG && git rev-parse
On Thu, Mar 28, 2013 at 04:52:15PM +0100, Michael Haggerty wrote:
> On 03/28/2013 04:38 PM, Jeff King wrote:
> > On Thu, Mar 28, 2013 at 04:34:19PM +0100, Michael Haggerty wrote:
> >
> >> Is there a simple way to verify an object name more strictly and convert
> >> it to an SHA1? I can only thin
On 03/28/2013 04:38 PM, Jeff King wrote:
> On Thu, Mar 28, 2013 at 04:34:19PM +0100, Michael Haggerty wrote:
>
>> Is there a simple way to verify an object name more strictly and convert
>> it to an SHA1? I can only think of solutions that require two commands,
>> like
>>
>> git cat-file -e $
On Thu, Mar 28, 2013 at 04:34:19PM +0100, Michael Haggerty wrote:
> Is there a simple way to verify an object name more strictly and convert
> it to an SHA1? I can only think of solutions that require two commands,
> like
>
> git cat-file -e $ARG && git rev-parse --verify $ARG
Is the rev-pa
On 03/28/2013 02:48 PM, Junio C Hamano wrote:
> I think it has always been about "is this well formed and we can turn it
> into a raw 20-byte object name?" and never about"does it exist?"
That's surprising. The man page says
--verify
The parameter given must be usable as a single, va
Jeff King writes:
> On Thu, Mar 28, 2013 at 02:04:27PM +0100, Michael Haggerty wrote:
>
>> $ git rev-parse --verify
>>
>> $ echo $?
>> 0
>>
>> [...]
>>
>> I believe that "git rev-parse --verify" is meant to verify t
On Thu, Mar 28, 2013 at 02:04:27PM +0100, Michael Haggerty wrote:
> $ git rev-parse --verify
>
> $ echo $?
> 0
>
> [...]
>
> I believe that "git rev-parse --verify" is meant to verify that the
> argument is an actual
On Junio's master, "git rev-parse --verify" accepts *any* 40-digit
hexadecimal number. For example, pass it 40 "1" characters, and it
accepts the argument:
$ git rev-parse --verify
$ echo $?
0
Obviously, my repo do
16 matches
Mail list logo
