On Wed, Nov 28, 2012 at 1:51 AM, Jeff King <peff@xxxxxxxx> wrote:
> On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras wrote:
>
>> > While "constant traffic" probably overstates the issue, these are not
>> > theoretical problems. I recall at least three cases in the last year
>> > or so where Git has seen breakage with Solaris or Mac OS X because
>> > of sed or tr incompatibilities, and I don't even read this list that
>> > thoroughly.
>>
>> Most of the *constant* traffic is about *theoretical*
>> incompatibilities, how much of that are real incompatibilities, it's
>> not known. _Some_ of the traffic is about real incompatibilities,
>> sure, but you could count only three cases *in a year*. It's not a
>> huge amount. And then, how man this year?
>>
>> Also, I would like references to those incompatibilities.
>
> Try:
>
> git log --grep='portab' -- '*.sh'
% git log --oneline --grep='portab' --since='2 years ago' --no-merges -- '*.sh'
6eafa6d submodules: don't stumble over symbolic links when cloning recursively
Somebody mentioned 'portable', but no problem was hit.
2718781 t9400: fix gnuism in grep
It's a test, and nobody was hit by any problem.
0dbe659 t5704: fix nonportable sed/grep usages
Apparently there was an issue, but this is a test.
93d5e0c t7810: avoid unportable use of "echo"
A problem, but in tests.
482ce70 tests: avoid nonportable {foo,bar} glob
Again, tests.
77e5726 t0050: fix printf format strings for portability
Tests.
So, this search didn't throw a single issue that affected users in two
years. Moving git sub-commands to python wouldn't change a thing.
Maybe shell wasn't the right language for the test system, but I don't
see anybody proposing it to be changed.
> Not all of the hits are shell portability fixes, but most of them are,
> and they are all in response to real, reported issues. The usual
> culprits are Solaris, BSD (including OS X), and the occasional GNUism.
> And that is only the ones that we fixed in response to bug reports for
> commits in the wild. Many more have been caught in review before needing
> a separate patch (grepping the list archive for 'portable' and '\.sh'
> yields 1800 messages).
>
> So dealing with shell portability is definitely something we do, and it
> is a minor pain.
First you have to separate the issues with the test system, because
that's not going to be changed. And then you have to separate the
*potential* issues and the *real* ones. You can spend all your time
doing "shell portability", but does that mean that you actually have a
problem? Maybe if you hadn't done anything, nobody would have noticed
there was a problem.
Sure, you will argue that we don't see the *real* issues, because they
were fixed preemptively, but the fact of the matter is that we will
never know. All we know is the reality we can observe, and the reality
is that we hit very few *real* issues outside the test system (feel
free to provide evidence to the contrary).
> But like you, I think we have been getting along reasonably well with
> shell scripts (and where it is not powerful enough, writing C). No
> solution is going to be free of portability issues (whether because of
> differing versions, because the tool is uncommon on certain platforms,
> or whatever). And because git-core's official API is shell-executable
> commands, any other language you write ends up looking a lot like shell
> anyway.
Agreed.
Cheers.
--
Felipe Contreras
--
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