Re: Python extension commands in git - request for policy change

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Nov 28, 2012, 02:06 UTC
Message-ID: <CAMP44s1jzUWm8BKxJR29RNWTWnxReExTeDTAKhk3mF3WJYNE0w@mail.gmail.com>
In-Reply-To: <20121128013943.GA23776@sigill.intra.peff.net>

On Wed, Nov 28, 2012 at 2:39 AM, Jeff King <peff@peff.net> wrote:

Show 15 quoted lines

> On Wed, Nov 28, 2012 at 02:22:09AM +0100, Felipe Contreras wrote:
>
>> 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).
>
> I think reports of breakage in the test scripts are relevant, because
> they are indicative that people _do_ run platforms that care about these
> issues, and if we were to write a lot of shell scripts, we would run
> across them more frequently. But the fact of the matter is that we don't
> write a lot of non-test shell scripts these days, which is part of the
> reason limiting your search to the last 2 years did not turn up many
> fixes outside the tests.

If we were to write a lot of shell scripts, and we were to apply the same standards as we do with the tests, which most likely wouldn't be the case; end-user scripts are way more important, specially porcelain.

Show 9 quoted lines

> There was a big push in 2006 and 2007 to port some of the hairier
> scripts to C. Try:
>
>   git log --no-renames --diff-filter=D \
>           --diff-filter=D --format='%ad %s' --date=short \
>           -- 'git-*.sh'
>
> A lot of it was motivated by portability and decent performance for
> common commands under Windows.

Good stuff indeed. I look forward to the day all main git porcelain commands are written in C (git-rebase I'm looking at you), there are not many left:

git-am git-bisect git-citool git-gui git-pull git-rebase git-stash git-submodule

> Anyway, there is not much point in debating the exact level of pain that
> shell portability causes us. Even if you accept that there is some, it
> is clearly not a major problem for the project.

Indeed.

-- 
Felipe Contreras