On 03/31/2014 11:30 PM, Junio C Hamano wrote:
> Michael Haggerty <mhag...@alum.mit.edu> 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 Haggerty
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to