On 03/31/2014 11:30 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
>
>> The test
>>
>> stdin -z create ref fails with zero new value
>>
>> actually passes an empty new value, not a zero new value. So rename
>> the test s/zero/empty/, and change the expected error from
>>
>> fatal: create $c given zero new value
>>
>> to
>>
>> fatal: create $c missing <newvalue>
>
> I have a feeling that "zero new value" might have been done by a
> non-native (like me) to say "no new value"; "missing newvalue"
> sounds like a good phrasing to use.
>
>> Of course, this makes the test fail now, so mark it
>> test_expect_failure. The failure will be fixed later in this patch
>> series.
>
> That sounds somewhat strange. Why not just give a single-liner to
> update-ref.c instead?
This is because there really is a difference between the two errors, and
"git update-ref" tries to emit distinct error messages for them:
* "zero new value" means that the new value was 0{40}
* "missing <newvalue>" means that the new value was absent
The problem is that it is not distinguishing between these two cases
correctly, and fixing *that* is more than a one-liner.
Michael
--
Michael Haggerty
mhagger@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html