Re: Requirements for integrating a new git subcommand

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Nov 23, 2012, 09:13 UTC
Message-ID: <50AF3E36.4080800@drmicha.warpmail.net>
In-Reply-To: <20121122221107.GA16069@thyrsus.com>

Eric S. Raymond venit, vidit, dixit 22.11.2012 23:11:

Show 22 quoted lines

> Shawn Pearce <spearce@spearce.org>:
>> [Lots of helpful stuff ended by]
>>> 4. How does "git help" work?  That is, how is a subcommand expected
>>> to know when it is being called to export its help text?
>>
>> IIRC "git help foo" runs "man git-foo".
> 
> OK, that makes sense.
> 
>>> 5. I don't see any extensions written in Python.  Are there any special
>>> requirements or exclusions for Python scripts?
>>
>> Nope, it just has to be executable. We don't have any current Python
>> code. IIRC the last Python code was the implementation of
>> git-merge-recursive, which was ported to C many years ago. We avoid
>> Python because it is not on every platform where Git is installed. Yes
>> Python is very portable and can be installed in many places, but we
>> prefer not to make it a requirement.
> 
> I find that odd.  You avoid Python but use shellscripts?  *blink*
> 
> One would think shellscripts were a much more serious portability problem.

Different versions of python can be a mess to deal with, also, at least with respect to standard modules being "standard" or not for a specific version.

In any case, the point is that we try to avoid *additional* dependencies. Shell and perl are given with the status quo.

That being said, we also have remote helpers in python. The testsuite can run tests depending on the availability of python.

Regarding git-weave, I'm wondering (without having looked at the code) how this relates to git-archiv and git-fast-import/export, i.e. how much this leverages existing infrastructure rather than reinventing the wheel. Do your "trees" correspond to a "git tree"?

Again, without having looked at the code, it seems to me that exploding blob and tree objects might give you a structure not much unlike weave's, and your instruction sheet resembles that of fast-import quite a bit (plus date fill-in etc.).

One could even dream about implementing this as a remote helper instead...

Michael