Re: What's in git.git

Hi,

On Thu, 28 Sep 2006, Petr Baudis wrote:

Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I got a letter
where Junio C Hamano [off-list ref] said that...

quoted

  + Git.pm lost Git.xs; its remnant still remains, though.
    Notably, we still compile x86_64 with -fPIC, and the top
    level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS} distinction
    and INSTALL talks about perl/blib/arch/auto.  I am torn
    between removing these and keeping them; on one hand, they
    are not needed and makes new developers wonder what the
    distinction between BASIC and ALL are.  On the other hand,
    we may eventually would want to reintroduce Git.xs in the
    future and keeping them might help us.  But on the third
    hand ;-), we can always resurrect it from the repository and
    that is the point of using git to keep track of the project,
    so removing them might not be such a big deal.  I'd like to
    decide between this two and push it out to 'master' before
    doing the -rc1.

FWIW, I'd say kill it all (perhaps except BASIC_*, I don't know about
that one) - we indeed can easily resurrect this, and that was the
presumption with which I've killed the rest of Git.xs. There's no point
in keeping legacy cruft around when we can take it back from the
history.

Perhaps we could throw a note to perl/Makefile saying

	# If you are thinking about adding Git.xs support, please note
	# that we have already been there before - see the #next branch
	# history for more-or-less working one already added, and also
	# the reason why it was removed for now.

so that noone wastes their time.

Having ranted so often about Git.xs, I feel like I have to apologize. It 
would be a better idea (IMHO) to put an effort into having the _option_ to 
use Git.xs, since it is so much more efficient. If it is a strict opt-in, 
I think it could remain in "next", and it would be much more likely that 
people took up the ball and worked towards libifying git.

Ciao,
Dscho