Dropping Git.pm (at least Git.xs)?

Dropping Git.pm (at least Git.xs)?

[Junio C Hamano]

I was reviewing the "next" tonight and ended up reverting a few
patches that came from Git.pm topic that touched fairly core
part of the system.

Parts of environment.c and sha1_file.c are fairly old code that
has "we start in one repository, do our work and exit" mentality
pretty much ingrained.  The reverted one was meant to minimally
work it around to allow switching between repositories.

The intention is good, but I felt keeping such hack without
thinking about what the semantics of switching repositories
should mean would harm eventual libification.

In the ideal world in admittably not so immediate future, I
would rather have a honestly libified git that encapsulates
git_dir, git_object_dir, git_index_file, etc. into a structure
("struct git_repository" perhaps) and passes a pointer to it to
functions like has_sha1_file(), get_sha1() and friends.
Probably to keep the changes manageable, we would start from one
instance of "struct git" that is the default, and existing
interfaces would become thin wrappers that pass the pointer to
that default one to the updated functions that are repo aware.

One great promise Git.pm topic showed, at least from my point of
view, was consolidation of core-wrapper functions various script
had.  In the hindsight, I should have pushed for that
consolidation a lot stronger while rejecting Git.xs (I
underestimated that Git.xs would introduce such portability
issues).  After all, existing Perl scripts did things without
having to use any .xs.

Since there is no serious user of Git.pm exists, especially
git-mv and git-fmt-merge-msg are now not in Perl anymore, I do
not think we are in great hurry to have Git.xs yet.  I would
expect that the most major customer of Git.xs to be gitweb
eventually, but to support it in persistent environment (read:
mod_perl) we would need to have multi-repo infrastructure in
place.  And I do not think we want a hacky one.

What bothered me most was that has_sha1_file() issue; I think it
is Ok for read_sha1_file() to return object contents from a
repository that is not the current repository even after the
eventual libification that each invocation of a function is told
in which repository to operate.  After all, we depend on object
name being a reliable handle to its contents, and if the caller
has a name of the object that is not in the current repository
and wants to get its contents, and if the system happens to know
the answer (even when it shouldn't have known -- the reason it
knows is only because the process happens to have switched to
that other repository in the past), not failing the request and
give the contents is acceptable.  It could even be considered a
feature and would be handy when writing cross repository (albeit
limited to local repositories) diff/merge tools, for example.

But has_sha1_file() is different.  It is used to check if it
exists in the current repository when the caller knows the
object name (and presumably its contents), so that the caller
can base its decision on what to do next based on the result.
It really should care what repository it is operating in.

The approach taken by the patch I reverted were minimal patch to
allow switching, which was OK for get_object() purposes, and did
not even attempt to define what the semantics of has_sha1_file()
and read_sha1_file() should be.

I think being able to switch repositories in a single process is
important needs to be designed, not hacked in.  I am sure there
certainly are other things that needs more thought (e.g. how
should grafts work across repositories), but I think nobody
knows what they are because we haven't thought about the issues
yet.

A few sentences to conclude this message.

 - I think the clean-up promise of Git.pm is great (e.g.
   safe_qx should be part of it not in git-svn alone).

 - I think Git.xs was a bit premature and raised the hurdle of
   cleaning up and consolidating various core-wrappers from
   existing Perl scripts into Git.pm and have them use Git.pm.
   It would be nice if we can drop this part for now, and do a
   bit more Perl-level clean-up first.

 - I think "repository" abstraction, if we are going to have
   one, should be designed from the core level if we are going
   to have it accessible from Git.xs.  Unfortunately I am not
   ready to invest great time and effort for core level
   libification at this moment.



-- 
VGER BF report: U 0.516772

Re: Dropping Git.pm (at least Git.xs)?

[Dennis Stosberg]

Junio C Hamano wrote:

> In the ideal world in admittably not so immediate future, I
> would rather have a honestly libified git that encapsulates
[...]
>  - I think the clean-up promise of Git.pm is great (e.g.
>    safe_qx should be part of it not in git-svn alone).
> 
>  - I think Git.xs was a bit premature and raised the hurdle of
>    cleaning up and consolidating various core-wrappers from
>    existing Perl scripts into Git.pm and have them use Git.pm.
>    It would be nice if we can drop this part for now, and do a
>    bit more Perl-level clean-up first.

Having perl bindings to git internals and sometime in the future to a
libified git is a great thing.  It will allow people to do interesting
things, quickly trying concepts without having to write any C code.
And I expect that gitweb can be sped up remarkably by using Git.pm (no
forking, parsing of command output often not necessary, easy caching of
frequently cached data across calls, etc)

So I think there are valid uses for Git.pm.

On the other hand there are the problems Junio mentioned.  And the
portability issues wit Git.pm:

 - Git has to be built with the same compiler perl was built with,
   which is a problem on many Solaris machines.
 - We need to generate position-independent code on some archs, but
   have no proper way to determine on which systems it is really
   necessary. 
 - It completely breaks cross-compiling.

And the gain is negligible at the moment: There are only two users
left: git-annotate and git-send-email.  The first one has already
been superseded by git-blame and the second one can easily be
converted back.

I think Git.pm would be a good candidate for the contrib section if
there is someone who keeps it up-to-date through the coming changes.
The only thing that would have to be kept in the main Makefile is the
option to generate position-independent code, defaulting to off.

Regards,
Dennis



-- 
VGER BF report: U 0.957499

Re: Dropping Git.pm (at least Git.xs)?

[Petr Baudis]

  Hi,

Dear diary, on Sun, Sep 03, 2006 at 01:34:31PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
>  - I think the clean-up promise of Git.pm is great (e.g.
>    safe_qx should be part of it not in git-svn alone).
> 
>  - I think Git.xs was a bit premature and raised the hurdle of
>    cleaning up and consolidating various core-wrappers from
>    existing Perl scripts into Git.pm and have them use Git.pm.
>    It would be nice if we can drop this part for now, and do a
>    bit more Perl-level clean-up first.
> 
>  - I think "repository" abstraction, if we are going to have
>    one, should be designed from the core level if we are going
>    to have it accessible from Git.xs.  Unfortunately I am not
>    ready to invest great time and effort for core level
>    libification at this moment.

  I basically agree on all three points - I will try to submit a patch
to implement get_object() purely in Git.pm reasonably soon, and will see
about introducing some actually designed repository division abstraction
when I get some time. I hope to see Git.xs come back again in few
months, but for now I have to concur that we should go back to the
drawing board.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: Dropping Git.pm (at least Git.xs)?

[Sam Vilain]

Dennis Stosberg wrote:
> Having perl bindings to git internals and sometime in the future to a
> libified git is a great thing.  It will allow people to do interesting
> things, quickly trying concepts without having to write any C code.
> And I expect that gitweb can be sped up remarkably by using Git.pm (no
> forking, parsing of command output often not necessary, easy caching of
> frequently cached data across calls, etc)

FWIW, I have been starting on a perl implementation.  It uses the
Git.pm, but not for anything *that* important.  It's still very young,
but once I have reading and writing files basically working, I'll
release it to CPAN separately - no reason it needs to be distributed
with Git itself.

See http://utsl.gen.nz/gitweb/?p=VCS-Git

I used this design to talk about Moose at YAPC::Europe 2006.
http://utsl.gen.nz/talks/moose/start.html

Sam.

Re: Dropping Git.pm (at least Git.xs)?

[Jakub Narebski]

Sam Vilain wrote:

> Dennis Stosberg wrote:
>> Having perl bindings to git internals and sometime in the future to a
>> libified git is a great thing.  It will allow people to do interesting
>> things, quickly trying concepts without having to write any C code.
>> And I expect that gitweb can be sped up remarkably by using Git.pm (no
>> forking, parsing of command output often not necessary, easy caching of
>> frequently cached data across calls, etc)
> 
> FWIW, I have been starting on a perl implementation.  It uses the
> Git.pm, but not for anything *that* important.  It's still very young,
> but once I have reading and writing files basically working, I'll
> release it to CPAN separately - no reason it needs to be distributed
> with Git itself.
> 
> See http://utsl.gen.nz/gitweb/?p=VCS-Git

Could you please put appropriate information on GitWiki
  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
Perhaps it would be good time to start new section, Git Implementations,
and put egit (Java GIT library and Eclipse plugin) there too.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Dropping Git.pm (at least Git.xs)?

[Petr Baudis]

Dear diary, on Sun, Sep 10, 2006 at 07:59:54PM CEST, I got a letter
where Sam Vilain <sam@vilain.net> said that...
> Dennis Stosberg wrote:
> > Having perl bindings to git internals and sometime in the future to a
> > libified git is a great thing.  It will allow people to do interesting
> > things, quickly trying concepts without having to write any C code.
> > And I expect that gitweb can be sped up remarkably by using Git.pm (no
> > forking, parsing of command output often not necessary, easy caching of
> > frequently cached data across calls, etc)
> 
> FWIW, I have been starting on a perl implementation.  It uses the
> Git.pm, but not for anything *that* important.  It's still very young,
> but once I have reading and writing files basically working, I'll
> release it to CPAN separately - no reason it needs to be distributed
> with Git itself.
> 
> See http://utsl.gen.nz/gitweb/?p=VCS-Git

I think those two can coexist quite well. Yours aims for a nice and
slick object interface, while mine is just about wrapping Git interface
in Perl, without building any elaborate object model (it would provide
any only if underlying libgit would in the future, I guess).

Now, I'm not actually opposed to making Git.pm provide more
object-oriented interface, and it is thus obvious that it might be due
to consider a merge of the two modules, but

  (i) Git.pm ought to stay bundled with Git, simply to be useful for Git
itself and the perl scripts it carries. Without Git.xs and associated
portability concerns, Git.pm might finally actually help things. :-)

  (ii) People would thus go mad about external dependencies like Moose
or even Class::Autouse, so Git.pm can't rely on anything like that
(unless it bundles it, which is not quite practical in case of Moose).

  (iii) (Besides, Moose may be the next totally cool and all-popular
thing in the world of Perl soon, but so far, I'd be personally careful
about using it for the "official" interface, since Git Perl developers
would apparently have to learn another way to do objects in Perl before
able to use Git, and other Perl developers going by couldn't read (and
fix/enhance) the code without doing the same.)


Dear diary, on Mon, Sep 11, 2006 at 12:13:01AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Could you please put appropriate information on GitWiki
>   http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
> Perhaps it would be good time to start new section, Git Implementations,
> and put egit (Java GIT library and Eclipse plugin) there too.

This really isn't a Git reimplementation (thankfully).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: Dropping Git.pm (at least Git.xs)?

[Jakub Narebski]

Petr Baudis wrote:

> Dear diary, on Mon, Sep 11, 2006 at 12:13:01AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Could you please put appropriate information on GitWiki
>>   http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>> Perhaps it would be good time to start new section, Git Implementations,
>> and put egit (Java GIT library and Eclipse plugin) there too.
> 
> This really isn't a Git reimplementation (thankfully).

Perhaps "language binding" would be better name...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git