Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> On Mon, 24 Sep 2007, Miles Bader wrote:
>> ...
>> In practice that's not an issue though -- every reasonable shell has
>> test as a builtin these days, so the "works when test is not a builtin"
>> criteria is really important only for robustness.
>
> AAAAAAAAAAAAAARRRRRGGGHHHHHHHHHHHH!
>
> _Exactly_ the same reasoning can be said about the old code: _every_
> reasonable shell can grok the code that used to be there!
>
> <rhetoric-question>
> So what exactly was your point again?
> </rhetoric-question>
The points are:
(1) The code used to be there is known to cause trouble with a
deployed shell on FreeBSD of some vintage. It may be true
that the shell is broken, but it does not matter much to
the end user on such systems if breakage is in shell or in
scripts --- the end result is that the user cannot benefit
from git, and we already happen to know the workaround,
which does not make the scripts less readable nor less
portable;
(2) It's not like people who work on git scripts share the
exact same style and tradition. While I do not personally
think there is much readability improvements between the
old code and the new code, if more people find the latter
easier to work with, it's better to switch to the new code
especially because there is no downside.
(2-a) Nobody finds the latter less readable nor impossible
to work with. Even I am not saying that; I only said
I do not think it improves.
(2-b) git is not an educational project. It can be done
elsewhere in a UNIX history class, not here, to teach
people that "case ... esac" used to be much more
preferred over "test" because often the latter was
not built-in and slower.
Regarding "$# != 0" vs "$# -ne 0", I agree with the patch by
David. If the variable were "$something_else", then it might
have been better to use the explicitly numeric form, but I think
any seasoned shell people is much more used to see $# and $? (or
$status after an earlier "status=$?") compared with numeric
string with "=" or "!=".
-
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
