From: Petr Baudis <hidden> Date: 2016-06-15 22:44:58
In order to keep this mail within sensible size, I have trimmed some of
the bits - basically, the default reply is usually ranging from "Fair
enough" to "Great!" :-)
On Tue, Jul 15, 2008 at 12:19:31AM +0200, Lea Wiemann wrote:
quoted
First, I don't think it's good idea at all to put the pipe-related stuff
to Git::Repo - this is botched up API just like the current one.
Well, they're more like helper methods. Since they don't fit into the
design goals of the Git::Repo API at all, I'd suggest we just
underscore-prefix them and take them out of the man page. (The only
reason why I hadn't done this is that gitweb uses $repo->cmd_output
extensively, so it'd end up with a lot of underscore calls. But I
suppose we can either alias _cmd_output to cmd_output in gitweb's
CachedRepo subclass, or live with $repo->_cmd_output calls.) Does
underscore-prefixing sound good to you?
I think this is one problematic point we keep hitting - my opinion is
that we _need_ such a wrapper _publically_, because it tends to be
actually the main use-case of Git.pm, and that this wrapper should be:
(i) both available standalone for commands like ls-remote
(ii) and available as part of Git::Repo instance, to have the
right arguments passed to Git automagically
So you define cmd_output() and seem to argue that this command should
not be called directly and is not interesting for the outside. But the
experience shows that the pipe interface is actually the _most_ used
part of the Git Perl API, and in fact you mentioned that as part of your
gitweb migration to Git::Repo, you will temporarily introduce calls to
_cmd_output(), the "internal" API. :-) Sure, it's only temporary, but
many won't have the luxury to adjust the Git::Repo API to provide all
the operations they need, and ultimately they will need to defer to the
pipe interface.
quoted
It should be actually very easy to start with moving all the pipe
functionality to Git::Command.
Creating a new (Git::Command) API is very much non-trivial, apart from
the fact that I'm not convinced that we need Git::Command, and that a
clean command interface neither falls out of Git.pm nor Git::Repo.
As I said, majority of Git API usage is actually the pipe API. So we
should figure out how to provide it. I agree that it's not immediately
within your scope, but you are introducing new Perl API and this just
needs to be embedded somewhere there consistently.
quoted
quoted
[Git::Commit->new, Git::Tag->new:]
+Calls to this method are free, since it does not check whether $sha1
+exists and has the right type. However, accessing any of the commit
+object's properties will fail if $sha1 is not a valid commit object.
This is nice idea, but I'd also provide a well-defined way for the user
to verify the object's validity at a good moment; basically, make load()
a public method. The user can deal with errors then and rely on
error-free behavior later.
No, you should never pass in an invalid SHA1 in the first place. The
above piece of documentation is just a warning that bugs will show up
delayed. IOW, this is not the right place to have your error handling.
If you're getting a SHA1 through the user-interface, check its existence
with get_sha1 before passing it to the constructor.
But that's an expensive operation, you need extra Git exec for this,
while all the Git commands can do the checks for you, if you give them
the chance.
I was doing pretty much this thing in Cogito (initially out of
necessity) and it made it ungodly slow for any kind of batch operations.
quoted
quoted
+Note that $sha1 must be the SHA1 of a commit object; tag objects are
+not dereferenced.
Why not?
Because the SHA1 might resolve to an object of the wrong type, which
means you have to do error handling in Git::Object objects; that's the
wrong place.
If tag-resolving is really needed, we can add an optional $type
parameter to get_sha1, which will cause get_sha1 to resolve the object
until a $type object is found, or return undef if the object is or
resolves to an object of the wrong type.
See above why I think you should reconsider requiring the explicit
"resolving" step.
I have resolving code in gitweb's git_get_sha1_or_die (which I didn't
implement in Git::Repo since it uses some customized error reporting).
The resolving code could conceivably be extracted and moved to get_sha1.
I think there are a few things to ponder and maybe discuss, so I'd do
that in a separate patch (if I get around it before the end of the project).
The thing that concerns me about this is that this might show that your
approach to error handling is not flexible enough for some real-world
usage and this might be a design mistake - is that not so? I didn't look
at the code.
quoted
quoted
[Snipped a lot of quoting --LW]
+=item $repo->repo_dir
+=item $repo->git_binary
+=item $repo->version
+sub _get_git_cmd {
This definitely does not belong to a Git::Repo object.
Which of those methods are you referring to? I think $repo->version
might reasonably be removed (and the code re-added to gitweb); I'll do
so unless you object. _get_git_cmd is already underscored, and repo_dir
and git_binary only access attributes passed in through the constructor,
so I think those three should stay.
Sorry, you're right about repo_dir and possibly git_binary. My main
concern was about the command pipe handling itself, but I elaborated on
that above already.
Again, the refs should be properly integrated into the object structure.
Really? I think it's generally fine for get_refs to exist and to live
in Git::Repo.
Its return value (currently an an arrayref of [$sha1, $object_type,
$ref_name] arrayrefs) might need improvement though, and I find the
$pattern parameter pretty suspect (in that it smells like a for-each-ref
wrapper). Since get_refs is unused at the moment (gitweb ended up
needing the slightly different show-ref), I'll remove it for now. (Same
thing about me not being a fan of premature API design applies.)
Just a note, the thing is that you might want to add some methods for
inspecting and mutating the refs, and at the same time this is not a
repository-specific concept, but you can get the same structure from
git ls-remote call. That's why I think it would make sense to make
a separate object out of it. But that's moot point now that the API
won't be there yet.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
From: Jakub Narebski <hidden> Date: 2016-06-15 22:44:58
Dnia piątek 18. lipca 2008 18:48, Petr Baudis napisał:
On Tue, Jul 15, 2008 at 12:19:31AM +0200, Lea Wiemann wrote:
quoted
No, you should never pass in an invalid SHA1 in the first place. The
above piece of documentation is just a warning that bugs will show up
delayed. IOW, this is not the right place to have your error handling.
If you're getting a SHA1 through the user-interface, check its existence
with get_sha1 before passing it to the constructor.
But that's an expensive operation, you need extra Git exec for this,
while all the Git commands can do the checks for you, if you give them
the chance.
I was doing pretty much this thing in Cogito (initially out of
necessity) and it made it ungodly slow for any kind of batch operations.
Lea probably would point out that thanks to '--batch-check' option
to git-cat-file, and "reuse => 1" option to ->get_bidi_pipe you would
need only one extra Git exec... BUT it is one extra Git exec per
entire Perl script (one per request, for example, for gitweb).
And it wouldn't help batching Perl script commands.
--
Jakub Narebski
Poland
From: Petr Baudis <hidden> Date: 2016-06-15 22:44:58
On Fri, Jul 18, 2008 at 07:05:05PM +0200, Jakub Narebski wrote:
Dnia piątek 18. lipca 2008 18:48, Petr Baudis napisał:
quoted
On Tue, Jul 15, 2008 at 12:19:31AM +0200, Lea Wiemann wrote:
quoted
quoted
No, you should never pass in an invalid SHA1 in the first place. The
above piece of documentation is just a warning that bugs will show up
delayed. IOW, this is not the right place to have your error handling.
If you're getting a SHA1 through the user-interface, check its existence
with get_sha1 before passing it to the constructor.
But that's an expensive operation, you need extra Git exec for this,
while all the Git commands can do the checks for you, if you give them
the chance.
I was doing pretty much this thing in Cogito (initially out of
necessity) and it made it ungodly slow for any kind of batch operations.
Lea probably would point out that thanks to '--batch-check' option
to git-cat-file, and "reuse => 1" option to ->get_bidi_pipe you would
need only one extra Git exec... BUT it is one extra Git exec per
entire Perl script (one per request, for example, for gitweb).
And it wouldn't help batching Perl script commands.
Even so, I don't like this restriction simply since it makes the usage
more complicated - in my commandline tool, I will be forced to write
my $csha1 = $repo->get_sha1($ARGV[0]);
$csha1 or die "a random inconsistent error message";
$repo->get_commit($csha1)
instead of
$repo->get_commit($ARGV[0]) # die if unresolved
and I don't understand why. Me and 80% of the scripts don't *care* about
some more graceful error handling, and if gitweb and the other 20%
(or less) do, *they* should do the extra work, not me.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
[$repo->_cmd_output:]
we _need_ such a wrapper _publically_, because it tends to be
actually the main use-case of Git.pm,
Well, sure, I happen to not be convinced, but it *may* be useful. The
point I'm trying to make is that it's not part of what I'm writing here.
as part of your gitweb migration to Git::Repo, you will temporarily
introduce calls to _cmd_output(), the "internal" API. :-) Sure, it's
only temporary, but many won't have the luxury to adjust the Git::Repo
API to provide all the operations they need, and ultimately they will
need to defer to the pipe interface.
Yup, and I'm actually fine with that. (I'll probably alias _cmd_output
to cmd_output in gitweb, just to make it clear that it is, for the
purpose of gitweb, a *supported* mode of operation.) If the
Git::Repo::_cmd_output API goes away, you'll have to insert a few lines
of code in gitweb, but that's it. Really, no big deal.
Also, gitweb isn't using cmd_output because it needs a pipe interface,
but because it needs a caching layer in between -- most applications
would do just fine with open calls.
As I said, majority of Git API usage is actually the pipe API. So we
should figure out how to provide it. I agree that it's not immediately
within your scope, but you are introducing new Perl API and this just
needs to be embedded somewhere there consistently.
Sure, but pleeeease not as part of this patch series! :-) Look, our
conversation is going something like this:
Lea: Here's a Perl API that fell out of my gitweb development for free.
Petr: I want a pony with the API!
Lea: But I don't have a pony. Can we please just go with the Perl API
as a start, even if I don't supply ponies with it?
(Cf. the very cute <http://c2.com/cgi/wiki?IwantaPony>.)
quoted
If you're getting a SHA1 through the user-interface, check its existence
with get_sha1 before passing it to the constructor.
But that's an expensive operation, you need extra Git exec for this,
For the gazillionth time in this thread, there is no extra exec. It's a
write to a bidirectional cat-file --batch-check pipe. It's not
expensive. Really. ;-)
quoted
I have resolving code in gitweb's git_get_sha1_or_die
The thing that concerns me about this is that this might show that your
approach to error handling is not flexible enough for some real-world
usage and this might be a design mistake - is that not so?
I don't think so; the error handling is fine. Given that I want
fine-granular error reporting for gitweb, there *needs* to be a
git_get_sha1_or_die function; you can't move that into the API.
-- Lea
From: Petr Baudis <hidden> Date: 2016-06-15 22:44:58
On Fri, Jul 18, 2008 at 08:09:48PM +0200, Lea Wiemann wrote:
Also, gitweb isn't using cmd_output because it needs a pipe interface,
but because it needs a caching layer in between -- most applications
would do just fine with open calls.
One of the points of the API is to abstract these out.
quoted
As I said, majority of Git API usage is actually the pipe API. So we
should figure out how to provide it. I agree that it's not immediately
within your scope, but you are introducing new Perl API and this just
needs to be embedded somewhere there consistently.
Sure, but pleeeease not as part of this patch series! :-) Look, our
conversation is going something like this:
Lea: Here's a Perl API that fell out of my gitweb development for free.
Petr: I want a pony with the API!
Lea: But I don't have a pony. Can we please just go with the Perl API
as a start, even if I don't supply ponies with it?
(Cf. the very cute <http://c2.com/cgi/wiki?IwantaPony>.)
I'm fine with that, as long as the version that enters into master will
have a pony so that we stay with a single pony within the codebase in
the end, not two ponies with differently shaped saddles.
But as I said, I'm going to work on that.
quoted
quoted
If you're getting a SHA1 through the user-interface, check its existence
with get_sha1 before passing it to the constructor.
But that's an expensive operation, you need extra Git exec for this,
For the gazillionth time in this thread, there is no extra exec. It's a
write to a bidirectional cat-file --batch-check pipe. It's not
expensive. Really. ;-)
But the API is still obnoxiously elaborate, as I complained in another
mail.
quoted
quoted
I have resolving code in gitweb's git_get_sha1_or_die
The thing that concerns me about this is that this might show that your
approach to error handling is not flexible enough for some real-world
usage and this might be a design mistake - is that not so?
I don't think so; the error handling is fine. Given that I want
fine-granular error reporting for gitweb, there *needs* to be a
git_get_sha1_or_die function; you can't move that into the API.
Wait, this doesn't compute here. The error handling is fine, but it is
actually not fine for gitweb. Can't we make it fine for everyone?
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:58
Hi,
On Fri, 18 Jul 2008, Lea Wiemann wrote:
Lea: Here's a Perl API that fell out of my gitweb development for free.
Petr: I want a pony with the API!
Lea: But I don't have a pony. Can we please just go with the Perl API
as a start, even if I don't supply ponies with it?
Johannes: *mumbles* no ponies? *mumbles further* Them cowboy coders keep
the ponies for themselves, eh? *mumbles and gets something to eat*
Ciao,
Dscho
From: Jakub Narebski <hidden> Date: 2016-06-15 22:44:58
On Fri, 18 July 2008, Petr Baudis wrote:
But the experience shows that the pipe interface is actually
the _most_ used part of the Git Perl API.
This made me curious which parts of Git.pm, the current Git Perl API,
are used most.
Here is some statistics on the usage of Git Perl API among built-in
and contrib commands.
From git commands in Perl the following include "use Git" in their
sources: git-cvsexportcommit, git-send-email, git-svn, and helper
script git-add--interactive. There are Perl scripts which do not
use Git.pm: git-archimport (which I think should be obsoleted or
moved to contrib), git-cvsimport, git-cvsserver, git-relink. This
means that half of Perl scripts use Git Perl API.
The situation is worse for scripts in 'contrib/'. From those, only
contrib/examples/git-remote.perl uses Git.pm; neither blameview,
continuous, git-import and import-tars in fast-import, setgitperms
and update-paranoid in hooks, stats, nor other Perl scripts in
examples (git-rerere, git-svnimport) include "use Git".
Below there are stats on how different commands from Git.pm are
used in mentioned Perl scripts:
1. git-add--interactive.perl uses Git.pm mainly to access color
configuration: 2 ->get_colorbool, 8 ->get_color, 1 ->config.
It also uses once ->repository() constuctor, and once
->repo_path().
This means that future Git::Config _has_ to have support for
color or colorbool valued configuration values.
2. git-cvsexportcommit.perl uses (besides ->repository() constructor)
only once ->config; so I guess that current interface wrapping
git-config should stay, because parsing whole config for such
situation would be overkill.
What is strange that git-cvsexportcommit.perl defines its own
safe_pipe_capture and xargs_safe_pipe_capture (!), and uses
them, open pipeline, backticks, and system() to call git commands.
3. git-send-email.perl uses 5 config, 2 config_bool, 2 ident_person
(for author and for committer), 1 version, and of course once
->repository() constructor.
Here we can see how to work around current API to: it uses
Git::config(@repo, "sendemail.identity") form, where
my $repo = eval { Git->repository() };
my @repo = $repo ? ($repo) : ();
to make it work both with git repository (using repo config), and
outside/without git repository, using only user and system git
config.
4. git-svn.perl (which is if I checked correctly third largest scripted
git command, after gitk-gui/gitk-wish and gitweb/gitweb.perl) uses:
3 x repository
28 x command_oneline
19 x command_noisy
18 x command
14 x command_output_pipe
1 x command_input_pipe
1 x git_try_cmd (and many "eval { command()/command_oneline() }")
2 x cat_blob
1 x hash_and_insert_object
1 x get_colorbool
(The above are all if I have not made mistake when counting commands)
Side note: git-svn is command which would get most out of
Git::Config, as it currently uses combination of "git config -l"
and "git config --get" (I guess that the code in question predates
machine-parseable "git config -l -z").
Note that all those statictics doesn't count how many times some
Git.pm method was called, only how many times it occurs in the code.
--
Jakub Narebski
Poland
From: Petr Baudis <hidden> Date: 2016-06-15 22:44:58
On Sat, Jul 19, 2008 at 10:54:24PM +0200, Jakub Narebski wrote:
On Fri, 18 July 2008, Petr Baudis wrote:
quoted
But the experience shows that the pipe interface is actually
the _most_ used part of the Git Perl API.
Note that I referred both to scripts that are part of Git and
(actually more) to various third-party scripts I wrote externally.
Here is some statistics on the usage of Git Perl API among built-in
and contrib commands.
Thanks!
The situation is worse for scripts in 'contrib/'. From those, only
contrib/examples/git-remote.perl uses Git.pm; neither blameview,
continuous, git-import and import-tars in fast-import, setgitperms
and update-paranoid in hooks, stats, nor other Perl scripts in
examples (git-rerere, git-svnimport) include "use Git".
I have actually once converted blameview to use Git locally, but in
the end never got around to submit it; I wonder if I have the source
still around somewhere. Not so important, I guess.
Below there are stats on how different commands from Git.pm are
used in mentioned Perl scripts:
2. git-cvsexportcommit.perl uses (besides ->repository() constructor)
only once ->config; so I guess that current interface wrapping
git-config should stay, because parsing whole config for such
situation would be overkill.
I don't understand. Parsing whole config happen will either happen in
git-config or in Git::Config, and the performance difference is so tiny
that it is not really worth the API complexity, I believe.
3. git-send-email.perl uses 5 config, 2 config_bool, 2 ident_person
(for author and for committer), 1 version, and of course once
->repository() constructor.
Here we can see how to work around current API to: it uses
Git::config(@repo, "sendemail.identity") form, where
my $repo = eval { Git->repository() };
my @repo = $repo ? ($repo) : ();
to make it work both with git repository (using repo config), and
outside/without git repository, using only user and system git
config.
With the envisioned model, it could use $git which would be either
a reference to a Git::Standalone singleton or Git::Repo instance.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
From: Jakub Narebski <hidden> Date: 2016-06-15 22:44:58
On Sat, 19 July 2008, Petr Baudis wrote:
On Sat, Jul 19, 2008 at 10:54:24PM +0200, Jakub Narebski wrote:
quoted
3. git-send-email.perl uses 5 config, 2 config_bool, 2 ident_person
(for author and for committer), 1 version, and of course once
->repository() constructor.
Here we can see how to work around current API to: it uses
Git::config(@repo, "sendemail.identity") form, where
my $repo = eval { Git->repository() };
my @repo = $repo ? ($repo) : ();
to make it work both with git repository (using repo config), and
outside/without git repository, using only user and system git
config.
With the envisioned model, it could use $git which would be either
a reference to a Git::Standalone singleton or Git::Repo instance.
So that the code would look like the following, instead:
my $git = new Git::Cmd; # or Git::Standalone, or Git::CommandFactory
my $repo = eval { Git->repository() };
$git = $repo if $repo;
and later use
$git->config('sendemail.identity');
By the way, git-svn can use command(...) instead of $repo->command(...)
because it sets $ENV{'GIT_DIR'} if it is unset... but I don't see
where Git.pm inserts 'git' to commands list...
--
Jakub Narebski
Poland
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:58
Hi,
On Sat, 19 Jul 2008, Jakub Narebski wrote:
From git commands in Perl the following include "use Git" in their
sources: git-cvsexportcommit, git-send-email, git-svn, and helper
script git-add--interactive. There are Perl scripts which do not
use Git.pm: git-archimport (which I think should be obsoleted or
moved to contrib), git-cvsimport, git-cvsserver, git-relink. This
means that half of Perl scripts use Git Perl API.
The situation is worse for scripts in 'contrib/'. From those, only
contrib/examples/git-remote.perl uses Git.pm; neither blameview,
continuous, git-import and import-tars in fast-import, setgitperms
and update-paranoid in hooks, stats, nor other Perl scripts in
examples (git-rerere, git-svnimport) include "use Git".
You call that "worse"? Pasky tried to convert all Perl scripts at once
IIRC, and my numerous problems just _making_ the Git scripts led me to
rewrite a few Perl scripts in C, so I could safely exclude the Perl
scripts from my personal fork.
I guess that it was this experience which prevented more of the old
scripts from being converted.
But your mention of git-add--interactive actually brings up my pet-peeve:
this script is the only Perl script needed for common operations, i.e. the
only reason msysGit has to ship bloated with Perl.
Ciao,
Dscho
From: Petr Baudis <hidden> Date: 2016-06-15 22:44:58
Hi,
On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
You call that "worse"? Pasky tried to convert all Perl scripts at once
IIRC, and my numerous problems just _making_ the Git scripts led me to
rewrite a few Perl scripts in C, so I could safely exclude the Perl
scripts from my personal fork.
I don't remember any concrete report of such problems ever reaching
me; exactly what trouble are you hitting with the Perl scripts using
Git.pm? I will be glad to try to fix it.
I guess that it was this experience which prevented more of the old
scripts from being converted.
But your mention of git-add--interactive actually brings up my pet-peeve:
this script is the only Perl script needed for common operations, i.e. the
only reason msysGit has to ship bloated with Perl.
_Many_ people seem to be using git-svn, whether we like it or not. ;-)
Also, isn't git-send-mail rather commonly used? (I wouldn't know, me
using stg mail.)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:58
Hi,
On Sun, 20 Jul 2008, Petr Baudis wrote:
On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
quoted
Pasky tried to convert all Perl scripts at once IIRC, and my numerous
problems just _making_ the Git scripts led me to rewrite a few Perl
scripts in C, so I could safely exclude the Perl scripts from my
personal fork.
I don't remember any concrete report of such problems ever reaching me;
exactly what trouble are you hitting with the Perl scripts using Git.pm?
I will be glad to try to fix it.
But your mention of git-add--interactive actually brings up my
pet-peeve: this script is the only Perl script needed for common
operations, i.e. the only reason msysGit has to ship bloated with
Perl.
_Many_ people seem to be using git-svn, whether we like it or not. ;-)
Well, they will just stop using it on msysGit, since nobody fixes git-svn
on msysGit.
Also, isn't git-send-mail rather commonly used? (I wouldn't know, me
using stg mail.)
send-mail does not work on Windows. See
http://code.google.com/p/msysgit/issues/detail?id=27
Yes, you read correctly. The issue exists since almost the birth of
msysGit. Torgil seems to have stopped working on it altogether. Two
other people have "starred" the issue, wanting to be notified of fixes but
not wanting to work on them.
To me, it seems that either the Windows folk is a lazy bunch of bums, or
they just do not care enough. Or both.
Note: I want to express very loudly here that I do not count Hannes Sixt
as Windows folk. Even if he seems to like cmd.exe for some perverse
reason, it is undisputable that his effort, and his effort alone, brought
the MinGW port to where it is now.
To sum it up, I think we can safely remove Perl from the msysGit installer
once add--interactive is a builtin. The download will be substantially
smaller, and Perl on msysGit was never exactly a speed demon, so it's
probably a good change from several angles.
Ciao,
Dscho
From: Petr Baudis <hidden> Date: 2016-06-15 22:44:58
Hi,
On Sun, Jul 20, 2008 at 02:33:46PM +0200, Johannes Schindelin wrote:
On Sun, 20 Jul 2008, Petr Baudis wrote:
quoted
On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
quoted
Pasky tried to convert all Perl scripts at once IIRC, and my numerous
problems just _making_ the Git scripts led me to rewrite a few Perl
scripts in C, so I could safely exclude the Perl scripts from my
personal fork.
I don't remember any concrete report of such problems ever reaching me;
exactly what trouble are you hitting with the Perl scripts using Git.pm?
I will be glad to try to fix it.
running Git in-place without correctly setting the prefix is not
supported anyway; git wrapper will still be using non-builtin commands
from the prefix location instead of your fresh build.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:58
Hi,
On Sun, 20 Jul 2008, Petr Baudis wrote:
On Sun, Jul 20, 2008 at 02:33:46PM +0200, Johannes Schindelin wrote:
quoted
On Sun, 20 Jul 2008, Petr Baudis wrote:
quoted
On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
quoted
Pasky tried to convert all Perl scripts at once IIRC, and my
numerous problems just _making_ the Git scripts led me to rewrite
a few Perl scripts in C, so I could safely exclude the Perl
scripts from my personal fork.
I don't remember any concrete report of such problems ever reaching
me; exactly what trouble are you hitting with the Perl scripts using
Git.pm? I will be glad to try to fix it.
running Git in-place without correctly setting the prefix is not
supported anyway; git wrapper will still be using non-builtin commands
from the prefix location instead of your fresh build.
There were none. Anyway, because Git makes it _really_ hard to run
in-place, I gave in. I run Git from $HOME/bin now.
That is not what I remember. I remember that I had the next issue right
away. I remember that there were problems with ActiveState Perl+Cygwin.
And I remember that the Git.xs was not merged in the end.
Anyway, this whole discussion is moot, methinks.
Let's concentrate back on the real issue: merging the two as-of-now
incompatible Perl modules. It really would be nice to have one pony with
one saddle in the end, so that the use of Lea's GSoC project is not
limited to gitweb with enabled caching.
Ciao,
Dscho
From: Petr Baudis <hidden> Date: 2016-06-15 22:44:58
On Sun, Jul 20, 2008 at 02:16:36AM +0200, Jakub Narebski wrote:
By the way, git-svn can use command(...) instead of $repo->command(...)
because it sets $ENV{'GIT_DIR'} if it is unset... but I don't see
where Git.pm inserts 'git' to commands list...
In _execv_git_cmd(), or did I misunderstand your question?
(I think that level of indirection is probably residuum of the XS
interface.)
Petr "Pasky" Baudis