* Re: [PATCH 7/7] Convert git-annotate to use Git.pm
From: Petr Baudis @ 2006-06-25 9:36 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
In-Reply-To: <20060625092719.GH3154@h4x0r5.com>
Dear diary, on Sun, Jun 25, 2006 at 11:27:23AM CEST, I got a letter
where Ryan Anderson <ryan@michonline.com> said that...
> I don't see that Git.pm provides the compatibility functionality we have
> stubbed out, here.
Please see [PATCH 2/7] Git.pm: Try to support ActiveState output pipe.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Petr Baudis @ 2006-06-25 9:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vfyhtopjm.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jun 25, 2006 at 05:57:33AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> >> - RPM target -- we probably acquired a new build-dependency in
> >> which case the .spec file needs to be updated;
> >
> > Well, perl is currently not listed even as a runtime dependency,
> > so does it really need to be listed as a build dependency?
>
> Really? I think rpmbuild is getting anything that matches "^use "
> and listing the perl modules as dependencies.
I had on my mind to depend only on modules that are part of the default
Perl distribution, since installing them from CPAN is a bother if you
are installing Git to your home directory. That is why we bundle Error.
All the modules we depend on should come bundled with Perl since 5.8.1.
Now, I'm not sure what our "cutoff" point is, and even if it is
something like 5.6.0 whether we can just require users of Perl older
than 5.8.1 (which should be only some rare and obscure systems anyway)
to install the modules from CPAN.
If not, we can just get rid of Scalar::Util and XSLoader and we should
be clean; XSLoader should be easy, Scalar::Util somewhat more messy
since we will have to get Error.pm own .xs as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH 7/7] Convert git-annotate to use Git.pm
From: Ryan Anderson @ 2006-06-25 9:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060625015434.29906.23422.stgit@machine.or.cz>
On Sun, Jun 25, 2006 at 03:54:34AM +0200, Petr Baudis wrote:
> -sub open_pipe {
> - if ($^O eq '##INSERT_ACTIVESTATE_STRING_HERE##') {
> - return open_pipe_activestate(@_);
> - } else {
> - return open_pipe_normal(@_);
> - }
> -}
> -
> -sub open_pipe_activestate {
> - tie *fh, "Git::ActiveStatePipe", @_;
> - return *fh;
> -}
> -
> -sub open_pipe_normal {
> - my (@execlist) = @_;
> -
> - my $pid = open my $kid, "-|";
> - defined $pid or die "Cannot fork: $!";
> -
> - unless ($pid) {
> - exec @execlist;
> - die "Cannot exec @execlist: $!";
> - }
> -
> - return $kid;
> -}
I don't see that Git.pm provides the compatibility functionality we have
stubbed out, here.
(It clearly has never been used, because there hasn't been a patch to
set the actual ActiveState string there.. 'MSWin32', btw.)
I suspect that the other scripts, that have more users, will see
regression complaints when the qx() calls get replaced by calls to
open(my $fh, "-|"), indirectly, in Git.pm
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] cvsimport: setup indexes correctly for ancestors and incremental imports
From: Junio C Hamano @ 2006-06-25 9:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Martin Langhoff, git
In-Reply-To: <20060625085359.GC21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sun, Jun 25, 2006 at 05:10:36AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> Please please please do not use --- between the cover letter and
>> commit message body if you choose to do the cover letter first.
>
> Oops, I suspect that I'm a huge offender in this regard in that case.
> Can I format my patch mails so that they look like natural replies _and_
> you can still apply them easily?
It's not a big deal.
I do it with scissors mark "-- >8 --" because I can use "git-am"
while still in GNUS with '|' (gnus-summary-pipe-output) on the
message, and immediately after that I can amend the commit with
"git-commit --amend" to remove everything up to the scissors
mark.
If you have --- then I have to save the message in a separate
file with 'C-o' (gnus-summary-save-article-mail), open the file
and remove up to that first --- in the editor, and then run
git-am on the file.
Only when the cover letter is short, I'd prefer Linus style,
which places cover letter material after the --- and the
diffstat, although that makes the message like top-posting.
^ permalink raw reply
* Re: [PATCH] cvsimport: setup indexes correctly for ancestors and incremental imports
From: Johannes Schindelin @ 2006-06-25 9:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64iqq6ab.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 24 Jun 2006, Junio C Hamano wrote:
> Please please please do not use --- between the cover letter and commit
> message body if you choose to do the cover letter first.
Sorry. Will not happen again.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git-fetch - repack in the background after fetching
From: Johannes Schindelin @ 2006-06-25 9:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git, junkio
In-Reply-To: <Pine.LNX.4.64.0606242049500.3747@g5.osdl.org>
Hi,
On Sat, 24 Jun 2006, Linus Torvalds wrote:
> However, the more worrisome thing about background repacking is that while
> it should be safe against normal users, if you have two _repacks_ at the
> same time, they can decide to remove each others packs. Yeah, yeah, that's
> pretty damn unlikely, but hey, "pretty damn unlikely" is not "impossible".
Why not introduce a lock file for repack?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvsimport: setup indexes correctly for ancestors and incremental imports
From: Petr Baudis @ 2006-06-25 8:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Martin Langhoff, git
In-Reply-To: <7v64iqq6ab.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jun 25, 2006 at 05:10:36AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Please please please do not use --- between the cover letter and
> commit message body if you choose to do the cover letter first.
Oops, I suspect that I'm a huge offender in this regard in that case.
Can I format my patch mails so that they look like natural replies _and_
you can still apply them easily?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH] git-commit: filter out log message lines only when editor was run.
From: Yann Dirson @ 2006-06-25 7:21 UTC (permalink / raw)
To: Marco Costalba; +Cc: junkio, GIT list
In-Reply-To: <e5bfff550606250008k702acfadm8860e9b672bced56@mail.gmail.com>
On Sun, Jun 25, 2006 at 09:08:02AM +0200, Marco Costalba wrote:
> 1) It's ok to let git-comit do not strip comment lines, it's already
> done by qgit.
That's great news :)
> 2) Please don't change git status output to use another symbol to mark
> comment lines because it will break line stripping code.
If it ever gets changed, it should anyway IMHO be made a parameter. A
strategy could be to make it customizable first, advertize this loudly
so tools adapt themselves to force the prefix to what suits them best,
and then eventually change the default in a major release.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] git-commit: filter out log message lines only when editor was run.
From: Marco Costalba @ 2006-06-25 7:08 UTC (permalink / raw)
To: Yann Dirson; +Cc: junkio, GIT list
In-Reply-To: <20060624094217.GB7851@nowhere.earth>
On 6/24/06, Yann Dirson <ydirson@altern.org> wrote:
> Junio wrote:
> > I agree with this in principle but we would need to make sure
> > that our own scripts do not expect that the message is cleaned
> > up when feeding a commit log message via stdin, -m or -F, and if
> > they do fix them before applying this patch.
>
> The only tools in git.git I could identify as using git-commit rather
> than commit-tree are:
>
> git-revert.sh: OK
> git-rebase.sh: only uses -C
>
> cogito, stgit, and pg also use commit-tree. Only qgit seems to be
> using git-commit, and probably makes use of this (mis)feature.
>
Yes, qgit uses git-commit, but issue is different.
qgit uses the output of git status as a 'default text' used in the
commit dialog. When commit button is pressed, after some message
editing by the user, the comment lines are stripped _before_ to save
the content of commit message in a temporary file to be used by
git-commit with -F option.
The comment stripping is done by this code:
msg = textEditMsg->text();
msg.remove(QRegExp("\\n\\s*#[^\\n]*")); // strip comments
msg.replace(QRegExp("[ \\t\\r\\f\\v]+\\n"), "\n"); // strip line trailing cruft
msg = msg.stripWhiteSpace();
as you see it rely on the '#' character.
So conclusions are:
1) It's ok to let git-comit do not strip comment lines, it's already
done by qgit.
2) Please don't change git status output to use another symbol to mark
comment lines because it will break line stripping code.
Marco
^ permalink raw reply
* Re: [PATCH] Rename safe_strncpy() to strlcpy().
From: Junio C Hamano @ 2006-06-25 5:29 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20060624140124.GA1323@ebar092.ebar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> This cleans up the use of safe_strncpy() even more. Since it has the
> same semantics as strlcpy() use this name instead.
> ---
>
> I've introduced a NO_STRLCPY variable in the Makefile. What do
> you think about this?
No strong preference -- I can go with either name. But people
with more BSD exposure than I am are probably used to see this
function as strlcpy(), so if that is the case let's use this
patch.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/7] Git.pm: Introduce ident() and ident_person() methods
From: Junio C Hamano @ 2006-06-25 5:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060625015751.GB21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index e794e44..79e82f5 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>
> BTW, please tell me if you want to redo the patches without any script
> updates (and how large portion of the patches to resend; my stg stack
> now has 28 patches and I'm finally using it for some real workload!)
> - given that the plan is to have the converted scripts only in pu
> (or entirely outside your tree) but full-fledged Git.pm in tree.
I'd avoid asking you to resend, but give me some time to see how
the series looks like first.
^ permalink raw reply
* Re: [PATCH 1/3] rebase: allow --merge option to handle patches merged upstream
From: Eric Wong @ 2006-06-25 4:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606250401490.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 24 Jun 2006, Eric Wong wrote:
>
> > + if test -n "`git-diff-index HEAD`"
>
> This is not a sufficient test if the patch was already merged to upstream.
> For example, you can have two patches which touched the same file, and one
> of them was applied to upstream, the other not. The test fails to see
> that. Or am I missing something?
This is just to tell if there's anything worth committing after a merge
is complete. If not, then it assumes it's been a) merged upstream or b)
empty in the first place (very unlikely).
--
Eric Wong
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Junio C Hamano @ 2006-06-25 3:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20060625012435.GZ21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> - RPM target -- we probably acquired a new build-dependency in
>> which case the .spec file needs to be updated;
>
> Well, perl is currently not listed even as a runtime dependency,
> so does it really need to be listed as a build dependency?
Really? I think rpmbuild is getting anything that matches "^use "
and listing the perl modules as dependencies.
>> - Make sure Git.xs builds and installed result works fine on
>> all platforms we care about, including Cygwin and other
>> non-Linux boxes.
>
> Unfortunately I don't have access to a lot of those. :-(
I don't either. That's why I would want to place something
low-impact on "next" to ask help from the users.
>> I'd even suggest we revert the changes to git-fmt-merge-msg to
>> keep it working for now, until the above worries are resolved.
>> Otherwise we cannot have it in "next" safely (and I REALLY _do_
>> want to have Git.pm infrastructure in "next" soonish).
>
> Yes, that sounds reasonable.
>
>> We can start using Git.xs and friends in some _new_ ancillary
>> programs, once we solve building and installing problems for
>> everybody. That way it would help us gain portability and
>> confidence without disrupting existing users.
>
> Well, I don't think it's very likely that Git.pm per se would be buggy
> on a certain specific platform - it should either work as well as
> everywhere else or not build at all, in which case you have disrupted
> the existing users anyway. :-) (But without disrupting anyone we won't
> get any bugreports and never get it fixed.)
>
> Perhaps other converted perl scripts can linger at least on the pu
> branch?
My preference is to keep your other conversion in "later"
mailbox, not even in "pu", to keep them from distracting me.
I'd like to have something low-impact (e.g. "git-mv" which I do
not use and I do not think Linus uses) along with the perl/
directory and build procedure in "next" soonish to make sure at
least things build and correctly install for everybody
(compiling and linking alone would not count as "correctly
install" while we have something like INSTALLSITEARCH gotcha).
After we are reasonably confident about the whole .xs stuff we
can revert the revert of git-fmt-merge-msg.
^ permalink raw reply
* Re: [RFC] git-fetch - repack in the background after fetching
From: Linus Torvalds @ 2006-06-25 3:53 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, junkio
In-Reply-To: <11511486003924-git-send-email-martin@catalyst.net.nz>
On Sat, 24 Jun 2006, Martin Langhoff wrote:
>
> Check whether we have a large set of unpacked objects and repack
> after the fetch, but don't for the user to wait for us. Conditional
> on core.autorepack =! no.
I don't think this is safe.
It's also done stupidly.
Instead of askign how many unpacked objects we have with the (expensive)
git-rev-list, why not just do
ls "$GIT_DIR/objects/00" | wc -l
which is pretty much guaranteed to be faster and easier.
However, the more worrisome thing about background repacking is that while
it should be safe against normal users, if you have two _repacks_ at the
same time, they can decide to remove each others packs. Yeah, yeah, that's
pretty damn unlikely, but hey, "pretty damn unlikely" is not "impossible".
Also, I think you'd want to repack with "-l", in case the thing is set up
with an alternate object directory.
Linus
^ permalink raw reply
* Re: [PATCH 0/7] Rework diff options
From: Junio C Hamano @ 2006-06-25 3:48 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git, Johannes Schindelin
In-Reply-To: <20060624201843.a5b4f7b9.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> This patch series cleans up diff output format options.
>
> This makes it possible to use any combination of --raw, -p, --stat and
> --summary options and they work as you would expect.
>
> These patches passed all test and are for the next branch. Patches 6 and
> 7 are optional.
Thanks, very nicely done. Tentatively placed all of them in
"pu"; the first "clean-up" is in "master".
Here are a few problems I have seen:
- "git show --stat HEAD" gives '---' marker as Johannes and you
have already discussed (I do not mind this that much though);
- "--cc" seems to be quite broken. "git show v1.0.0" nor "git
diff-tree --pretty --cc v1.0.0" does not give the log
message, and gives something quite confused instead. I think
it is showing "-m -p" followed by "--cc".
We may find more minor breakages, in addition to these, but I am
reasonably sure we should be able to fix them in-tree.
^ permalink raw reply
* New Now you have chance to do it Revel in
From: Hillary @ 2006-06-25 3:27 UTC (permalink / raw)
To: glenda
Dear client.
Have more success with women and impress them with your power and stamina in bed
You are just a couple of clicks away from our great prices and handy shipment
World’s greatest brands produce these goods in top class labs with latest technologies.
Take a look: http://www.sluggishcl.com
The quality is realt high and the prices are the cheapest on the market!
^ permalink raw reply
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Junio C Hamano @ 2006-06-25 3:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060625014703.29304.12715.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> dst_ on #git reported that on Solaris 9, Perl was built by Sun CC
> and perl/ is therefore being built with it as well, while the rest
> of Git is built with gcc. The problem (the first one visible, anyway)
> is that we passed perl/ even various gcc-specific options. This
> separates those to a special variable.
>
> This is not really meant for an application yet since it's not clear
> if it will alone help anything.
Do things link and work fine if we do not have the GCC specific
options?
I would question why the rest of git is not built with Sun CC as
well if that is the case.
^ permalink raw reply
* Re: [PATCH 01/12] Introduce Git.pm (v4)
From: Junio C Hamano @ 2006-06-25 3:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060624130234.GT21864@pasky.or.cz>
ePetr Baudis <pasky@suse.cz> writes:
>> Is there a way from the environment to override this behaviour,
>> so that we can run the tests properly? I think PERL5LIB and
>> PERLLIB are defeated by having -I there (that's why I said I
>> liked what Fredrik did with his Python script, which appends the
>> final installed location to the search path). I think unshift
>> into @INC by hand (i.e. without even using use lib "$path")
>> would do what we want, but I feel that is a bit too ugly just
>> for the testing X-<.
>
> PERL5LIB and use lib at the same time works for me. Anyway, with the
> second patch I've sent things should work well even if you don't have
> Git.pm installed anywhere yet.
Sorry, I am not sure it "works for me" -- which one take
precedence for this?
$ head -n 2 script.perl
#!/usr/bin/perl -w -I /path/a
use lib "/path/b";
$ ./script.perl ;# invocation #1
$ PERL5LIB=/path/c ./script.perl ;# invocation #2
Precedence between the in-script -I and "use lib" are
irrelevant, but unless PERL5LIB takes precedence and the
invocation #2 takes Git.pm from /path/c my previous patch
to make sure test uses freshly built one does not work.
>> diff --git a/perl/Makefile.PL b/perl/Makefile.PL
>> index 54e8b20..92c140d 100644
>> --- a/perl/Makefile.PL
>> +++ b/perl/Makefile.PL
>> @@ -3,7 +3,7 @@ use ExtUtils::MakeMaker;
>> sub MY::postamble {
>> return <<'MAKE_FRAG';
>> instlibdir:
>> - @echo $(INSTALLSITELIB)
>> + @echo $(INSTALLSITEARCH)
>>
>> MAKE_FRAG
>> }
>
> Oh, yes; that line came from the time when we had no .xs yet. It is not
> visible here since both arch-specific and non-arch-specific libraries
> get installed to ~/lib.
OK. Thanks.
^ permalink raw reply
* Re: [RFC] git-fetch - repack in the background after fetching
From: Junio C Hamano @ 2006-06-25 3:12 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <11511486003924-git-send-email-martin@catalyst.net.nz>
Martin Langhoff <martin@catalyst.net.nz> writes:
> This is a follow up to a similar patch earlier
> http://www.gelato.unsw.edu.au/archives/git/0605/21401.html -- is there
> interest in making GIT more friendly to users who don't know or care
> about packing and repacking their repos?
I would be a bit worried about the niced background repack
racing against another instance of itself spawned by the same
parent.
> I loathe to do this conditionally only on the count of unpacked
> objects. If there's a quick'n'dirty way of asking portably whether
> the machine is busy or otherwise resource-constrained (ie: on battery)
> it should use it to avoid running repack at inconvenient times.
count-objects might be lighter weight than rev-list --unpacked.
If you mean to make core.autorepack to be boolean, checking for
string 'no' is not the right way.
git repo-config --bool --get core.autorepack
But it does not matter if that variable is a string that is
almost always true unless the value is "no".
^ permalink raw reply
* Re: [PATCH] cvsimport: setup indexes correctly for ancestors and incremental imports
From: Junio C Hamano @ 2006-06-25 3:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.63.0606242111250.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> How about this on top of your patch (which fixes things with my setup):
>
> ---
> [PATCH] cvsimport: always set $ENV{GIT_INDEX_FILE} to $index{$branch}
>
> Also, make sure that the initial git-read-tree is performed.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> ---
Please please please do not use --- between the cover letter and
commit message body if you choose to do the cover letter first.
Superficial look tells me this would be OK, so it will go to
"next". Please fix things up as needed and let's have this in
upcoming 1.4.1 whenever that happens.
^ permalink raw reply
* Re: [PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency
From: Junio C Hamano @ 2006-06-25 3:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20060625014009.GA21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> This one should do a better job; if we quote, let's do it proper. :-)
>
> +PERL_DEFINE = $(ALL_CFLAGS) -DGIT_VERSION='"$(GIT_VERSION)"'
> +PERL_DEFINE_SQ = $(subst ','\'',$(PERL_DEFINE))
> +PERL_LIBS = $(EXTLIBS)
> +PERL_LIBS_SQ = $(subst ','\'',$(PERL_LIBS))
> +perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
> (cd perl && $(PERL_PATH) Makefile.PL \
> + PREFIX='$(prefix_SQ)' \
> + DEFINE='$(PERL_DEFINE_SQ)' \
> + LIBS='$(PERL_LIBS)')
Yes let's ;-). You obviously meant PERL_LIBS_SQ on the last line.
During our a handful piecemeal patch exchange back-and-forth on
the list, most of the patches did not apply mechanically, so I
rolled them up and have pushed out the result in "pu" and it
will mirror out shortly. I am reasonably sure it is in much
better shape than 24 hours ago; could you double check the
result for me please?
And I earlier said...
Pasky, can we first iron out kinks in the build procedure and
installation before converting existing programs further? The
things I worry about currently are:
- the SITELIBARCH gotcha I sent you a message about (and you
responded to it already -- was that an Acked-by?);
- RPM target -- we probably acquired a new build-dependency in
which case the .spec file needs to be updated;
- Make sure Git.xs builds and installed result works fine on
all platforms we care about, including Cygwin and other
non-Linux boxes.
I'd even suggest we revert the changes to git-fmt-merge-msg to
keep it working for now, until the above worries are resolved.
Otherwise we cannot have it in "next" safely (and I REALLY _do_
want to have Git.pm infrastructure in "next" soonish).
We can start using Git.xs and friends in some _new_ ancillary
programs, once we solve building and installing problems for
everybody. That way it would help us gain portability and
confidence without disrupting existing users.
I think we have cleared SITELIBARCH, and Git.xs building is in
testable state for wider audience. The remaining hurdles are to
make sure the RPM target is still sensible, and fix the test
scheme.
Now, I am clueless about RPM, so help is very much appreciated.
About the testsuite, I think with the way git-fmt-merge-msg (and
other Perl scripts that will use Git.pm) is munged on the
initial line "#!/usr/bin/perl -I$(installedpath)", the test
scheme is seriously broken. To see how yourself, have a good
working version of Git.pm and friends in the path your
git-fmt-merge-msg's first line points at, apply the following
patch to perl/Git.pm in your source tree and run "make test".
It will pass t5700-clone-reference.sh test, which does "git
pull" (and uses git-fmt-merge-msg) without problems X-<.
diff --git a/perl/Git.pm b/perl/Git.pm
index 7bbb5be..c9121f4 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1,3 +1,5 @@
+syntax error
+
=head1 NAME
Git - Perl interface to the Git version control system
This is (as I said in a separate message earlier) because -I on
the first line (and the command line) seems to take precedence
over PERL5LIB we set up in the test harness, so the test does
not find the broken version you think you are testing. And
after it tests out OK, you install it and suffer from the
breakage. This is bad.
I am not sure what the right way to fix it, though. Obviously,
we could do something like the following:
diff --git a/Makefile b/Makefile
index 3a67578..3350be3 100644
--- a/Makefile
+++ b/Makefile
@@ -517,9 +517,12 @@ common-cmds.h: Documentation/git-*.txt
chmod +x $@+
mv $@+ $@
-$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
+$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/Makefile
+$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
rm -f $@ $@+
- sed -e '1s|#!.*perl\(.*\)|#!$(PERL_PATH_SQ)\1 -I'"$$(make -s -C perl instlibdir)"'|' \
+ INSTLIBDIR=$$(make -s -C perl instlibdir) && \
+ sed -e '1s|#!.*perl\(.*\)|#!$(PERL_PATH_SQ)\1|' \
+ -e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.perl >$@+
chmod +x $@+
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index f86231e..e8fad02 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -5,6 +5,7 @@ #
# Read .git/FETCH_HEAD and make a human readable merge message
# by grouping branches and tags together to form a single line.
+unshift @INC, '@@INSTLIBDIR@@';
use strict;
use Git;
use Error qw(:try);
which is in line with what git-merge-recursive does, but it is
not really what usual Perl modules and scripts do. It is
bending backwards to support testing which does not feel right.
The additional dependency to perl/Makefile is needed regardless
of this tentative fix -- you cannot run make -C perl before
building perl/Makefile.
^ permalink raw reply related
* Re: [PATCH 1/3] rebase: allow --merge option to handle patches merged upstream
From: Johannes Schindelin @ 2006-06-25 2:04 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <11511989902239-git-send-email-normalperson@yhbt.net>
Hi,
On Sat, 24 Jun 2006, Eric Wong wrote:
> + if test -n "`git-diff-index HEAD`"
This is not a sufficient test if the patch was already merged to upstream.
For example, you can have two patches which touched the same file, and one
of them was applied to upstream, the other not. The test fails to see
that. Or am I missing something?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/7] Git.pm: Introduce ident() and ident_person() methods
From: Petr Baudis @ 2006-06-25 1:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060625015421.29906.50002.stgit@machine.or.cz>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index e794e44..79e82f5 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
BTW, please tell me if you want to redo the patches without any script
updates (and how large portion of the patches to resend; my stg stack
now has 28 patches and I'm finally using it for some real workload!)
- given that the plan is to have the converted scripts only in pu
(or entirely outside your tree) but full-fledged Git.pm in tree.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* [PATCH 5/7] Make it possible to set up libgit directly (instead of from the environment)
From: Petr Baudis @ 2006-06-25 1:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060625015421.29906.50002.stgit@machine.or.cz>
This introduces a setup_git() function which is essentialy a (public)
backend for setup_git_env() which lets anyone specify custom sources
for the various paths instead of environment variables. Since the repositories
may get switched on the fly, this also updates code that caches paths to
invalidate them properly; I hope neither of those is a sweet spot.
It is used by Git.xs' xs__call_gate() to set up per-repository data
for libgit's consumption. No code actually takes advantage of it yet
but get_object() will in the next patches.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
cache.h | 3 +++
commit.c | 23 +++++++++++++++++++----
environment.c | 45 +++++++++++++++++++++++++++++++++++++++------
perl/Git.pm | 8 ++++----
perl/Git.xs | 16 +++++++++++++++-
sha1_file.c | 30 ++++++++++++++++++++++++------
sha1_name.c | 10 ++++++++--
7 files changed, 112 insertions(+), 23 deletions(-)
diff --git a/cache.h b/cache.h
index efeafea..9844e88 100644
--- a/cache.h
+++ b/cache.h
@@ -116,6 +116,9 @@ extern struct cache_entry **active_cache
extern unsigned int active_nr, active_alloc, active_cache_changed;
extern struct cache_tree *active_cache_tree;
+extern void setup_git(char *new_git_dir, char *new_git_object_dir,
+ char *new_git_index_file, char *new_git_graft_file);
+
#define GIT_DIR_ENVIRONMENT "GIT_DIR"
#define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
#define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY"
diff --git a/commit.c b/commit.c
index 946615d..6c4acc2 100644
--- a/commit.c
+++ b/commit.c
@@ -163,6 +163,14 @@ int register_commit_graft(struct commit_
return 0;
}
+void free_commit_grafts(void)
+{
+ int pos = commit_graft_nr;
+ while (pos >= 0)
+ free(commit_graft[pos--]);
+ commit_graft_nr = 0;
+}
+
struct commit_graft *read_graft_line(char *buf, int len)
{
/* The format is just "Commit Parent1 Parent2 ...\n" */
@@ -215,11 +223,18 @@ int read_graft_file(const char *graft_fi
static void prepare_commit_graft(void)
{
static int commit_graft_prepared;
- char *graft_file;
+ static char *last_graft_file;
+ char *graft_file = get_graft_file();
+
+ if (last_graft_file) {
+ if (!strcmp(graft_file, last_graft_file))
+ return;
+ free_commit_grafts();
+ }
+ if (last_graft_file)
+ free(last_graft_file);
+ last_graft_file = strdup(graft_file);
- if (commit_graft_prepared)
- return;
- graft_file = get_graft_file();
read_graft_file(graft_file);
commit_graft_prepared = 1;
}
diff --git a/environment.c b/environment.c
index 3de8eb3..6b64d11 100644
--- a/environment.c
+++ b/environment.c
@@ -21,28 +21,61 @@ char git_commit_encoding[MAX_ENCODING_LE
int shared_repository = PERM_UMASK;
const char *apply_default_whitespace = NULL;
+static int dyn_git_object_dir, dyn_git_index_file, dyn_git_graft_file;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
-static void setup_git_env(void)
+
+void setup_git(char *new_git_dir, char *new_git_object_dir,
+ char *new_git_index_file, char *new_git_graft_file)
{
- git_dir = getenv(GIT_DIR_ENVIRONMENT);
+ git_dir = new_git_dir;
if (!git_dir)
git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
- git_object_dir = getenv(DB_ENVIRONMENT);
+
+ if (dyn_git_object_dir)
+ free(git_object_dir);
+ git_object_dir = new_git_object_dir;
if (!git_object_dir) {
git_object_dir = xmalloc(strlen(git_dir) + 9);
sprintf(git_object_dir, "%s/objects", git_dir);
+ dyn_git_object_dir = 1;
+ } else {
+ dyn_git_object_dir = 0;
}
+
+ if (git_refs_dir)
+ free(git_refs_dir);
git_refs_dir = xmalloc(strlen(git_dir) + 6);
sprintf(git_refs_dir, "%s/refs", git_dir);
- git_index_file = getenv(INDEX_ENVIRONMENT);
+
+ if (dyn_git_index_file)
+ free(git_index_file);
+ git_index_file = new_git_index_file;
if (!git_index_file) {
git_index_file = xmalloc(strlen(git_dir) + 7);
sprintf(git_index_file, "%s/index", git_dir);
+ dyn_git_index_file = 1;
+ } else {
+ dyn_git_index_file = 0;
}
- git_graft_file = getenv(GRAFT_ENVIRONMENT);
- if (!git_graft_file)
+
+ if (dyn_git_graft_file)
+ free(git_graft_file);
+ git_graft_file = new_git_graft_file;
+ if (!git_graft_file) {
git_graft_file = strdup(git_path("info/grafts"));
+ dyn_git_graft_file = 1;
+ } else {
+ dyn_git_graft_file = 0;
+ }
+}
+
+static void setup_git_env(void)
+{
+ setup_git(getenv(GIT_DIR_ENVIRONMENT),
+ getenv(DB_ENVIRONMENT),
+ getenv(INDEX_ENVIRONMENT),
+ getenv(GRAFT_ENVIRONMENT));
}
char *get_git_dir(void)
diff --git a/perl/Git.pm b/perl/Git.pm
index 1c3a2ec..c490e0c 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -92,6 +92,7 @@ increate nonwithstanding).
use Carp qw(carp croak); # but croak is bad - throw instead
use Error qw(:try);
use Cwd qw(abs_path);
+use Scalar::Util;
require XSLoader;
XSLoader::load('Git', $VERSION);
@@ -822,11 +823,10 @@ sub _call_gate {
if (defined $self) {
# XXX: We ignore the WorkingCopy! To properly support
# that will require heavy changes in libgit.
+ # For now, when we will need to do it we could temporarily
+ # chdir() there and then chdir() back after the call is done.
- # XXX: And we ignore everything else as well. libgit
- # at least needs to be extended to let us specify
- # the $GIT_DIR instead of looking it up in environment.
- #xs_call_gate($self->{opts}->{Repository});
+ xs__call_gate(Scalar::Util::refaddr($self), $self->repo_path());
}
# Having to call throw from the C code is a sure path to insanity.
diff --git a/perl/Git.xs b/perl/Git.xs
index 2fd1c67..4e85d69 100644
--- a/perl/Git.xs
+++ b/perl/Git.xs
@@ -59,7 +59,21 @@ BOOT:
}
-# /* TODO: xs_call_gate(). See Git.pm. */
+void
+xs__call_gate(repoid, git_dir)
+ long repoid;
+ char *git_dir;
+CODE:
+{
+ static long last_repoid;
+ if (repoid != last_repoid) {
+ setup_git(git_dir,
+ getenv(DB_ENVIRONMENT),
+ getenv(INDEX_ENVIRONMENT),
+ getenv(GRAFT_ENVIRONMENT));
+ last_repoid = repoid;
+ }
+}
const char *
diff --git a/sha1_file.c b/sha1_file.c
index c80528b..8d24f50 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -126,16 +126,22 @@ static void fill_sha1_path(char *pathbuf
char *sha1_file_name(const unsigned char *sha1)
{
static char *name, *base;
+ static const char *last_objdir;
+ const char *sha1_file_directory = get_object_directory();
- if (!base) {
- const char *sha1_file_directory = get_object_directory();
+ if (!last_objdir || strcmp(last_objdir, sha1_file_directory)) {
int len = strlen(sha1_file_directory);
+ if (base)
+ free(base);
base = xmalloc(len + 60);
memcpy(base, sha1_file_directory, len);
memset(base+len, 0, 60);
base[len] = '/';
base[len+3] = '/';
name = base + len + 1;
+ if (last_objdir)
+ free((char *) last_objdir);
+ last_objdir = strdup(sha1_file_directory);
}
fill_sha1_path(name, sha1);
return base;
@@ -145,14 +151,20 @@ char *sha1_pack_name(const unsigned char
{
static const char hex[] = "0123456789abcdef";
static char *name, *base, *buf;
+ static const char *last_objdir;
+ const char *sha1_file_directory = get_object_directory();
int i;
- if (!base) {
- const char *sha1_file_directory = get_object_directory();
+ if (!last_objdir || strcmp(last_objdir, sha1_file_directory)) {
int len = strlen(sha1_file_directory);
+ if (base)
+ free(base);
base = xmalloc(len + 60);
sprintf(base, "%s/pack/pack-1234567890123456789012345678901234567890.pack", sha1_file_directory);
name = base + len + 11;
+ if (last_objdir)
+ free((char *) last_objdir);
+ last_objdir = strdup(sha1_file_directory);
}
buf = name;
@@ -170,14 +182,20 @@ char *sha1_pack_index_name(const unsigne
{
static const char hex[] = "0123456789abcdef";
static char *name, *base, *buf;
+ static const char *last_objdir;
+ const char *sha1_file_directory = get_object_directory();
int i;
- if (!base) {
- const char *sha1_file_directory = get_object_directory();
+ if (!last_objdir || strcmp(last_objdir, sha1_file_directory)) {
int len = strlen(sha1_file_directory);
+ if (base)
+ free(base);
base = xmalloc(len + 60);
sprintf(base, "%s/pack/pack-1234567890123456789012345678901234567890.idx", sha1_file_directory);
name = base + len + 11;
+ if (last_objdir)
+ free((char *) last_objdir);
+ last_objdir = strdup(sha1_file_directory);
}
buf = name;
diff --git a/sha1_name.c b/sha1_name.c
index cd85d1f..1451cb6 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -12,15 +12,21 @@ static int find_short_object_filename(in
char hex[40];
int found = 0;
static struct alternate_object_database *fakeent;
+ static const char *last_objdir;
+ const char *objdir = get_object_directory();
- if (!fakeent) {
- const char *objdir = get_object_directory();
+ if (!last_objdir || strcmp(last_objdir, objdir)) {
int objdir_len = strlen(objdir);
int entlen = objdir_len + 43;
+ if (fakeent)
+ free(fakeent);
fakeent = xmalloc(sizeof(*fakeent) + entlen);
memcpy(fakeent->base, objdir, objdir_len);
fakeent->name = fakeent->base + objdir_len + 1;
fakeent->name[-1] = '/';
+ if (last_objdir)
+ free((char *) last_objdir);
+ last_objdir = strdup(objdir);
}
fakeent->next = alt_odb_list;
^ permalink raw reply related
* [PATCH 7/7] Convert git-annotate to use Git.pm
From: Petr Baudis @ 2006-06-25 1:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060625015421.29906.50002.stgit@machine.or.cz>
Together with the other converted scripts, this is probably still pu
material; it appears to work fine for me, though. The speed gain from
get_object() is about 10% (I expected more...).
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-annotate.perl | 167 ++++++++++-------------------------------------------
1 files changed, 31 insertions(+), 136 deletions(-)
diff --git a/git-annotate.perl b/git-annotate.perl
index a6a7a48..d924e87 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -11,6 +11,7 @@ use strict;
use Getopt::Long;
use POSIX qw(strftime gmtime);
use File::Basename qw(basename dirname);
+use Git;
sub usage() {
print STDERR "Usage: ${\basename $0} [-s] [-S revs-file] file [ revision ]
@@ -29,7 +30,7 @@ sub usage() {
exit(1);
}
-our ($help, $longrev, $rename, $rawtime, $starting_rev, $rev_file) = (0, 0, 1);
+our ($help, $longrev, $rename, $rawtime, $starting_rev, $rev_file, $repo) = (0, 0, 1);
my $rc = GetOptions( "long|l" => \$longrev,
"time|t" => \$rawtime,
@@ -52,6 +53,8 @@ my @stack = (
},
);
+$repo = Git->repository();
+
our @filelines = ();
if (defined $starting_rev) {
@@ -102,15 +105,11 @@ while (my $bound = pop @stack) {
push @revqueue, $head;
init_claim( defined $starting_rev ? $head : 'dirty');
unless (defined $starting_rev) {
- my $diff = open_pipe("git","diff","-R", "HEAD", "--",$filename)
- or die "Failed to call git diff to check for dirty state: $!";
-
- _git_diff_parse($diff, $head, "dirty", (
- 'author' => gitvar_name("GIT_AUTHOR_IDENT"),
- 'author_date' => sprintf("%s +0000",time()),
- )
- );
- close($diff);
+ my %ident;
+ @ident{'author', 'author_email', 'author_date'} = $repo->ident('author');
+ my $diff = $repo->command_output_pipe('diff', '-R', 'HEAD', '--', $filename);
+ _git_diff_parse($diff, $head, "dirty", %ident);
+ $repo->command_close_pipe($diff);
}
handle_rev();
@@ -181,8 +180,7 @@ sub git_rev_list {
open($revlist, '<' . $rev_file)
or die "Failed to open $rev_file : $!";
} else {
- $revlist = open_pipe("git-rev-list","--parents","--remove-empty",$rev,"--",$file)
- or die "Failed to exec git-rev-list: $!";
+ $revlist = $repo->command_output_pipe('rev-list', '--parents', '--remove-empty', $rev, '--', $file);
}
my @revs;
@@ -191,7 +189,7 @@ sub git_rev_list {
my ($rev, @parents) = split /\s+/, $line;
push @revs, [ $rev, @parents ];
}
- close($revlist);
+ $repo->command_close_pipe($revlist);
printf("0 revs found for rev %s (%s)\n", $rev, $file) if (@revs == 0);
return @revs;
@@ -200,8 +198,7 @@ sub git_rev_list {
sub find_parent_renames {
my ($rev, $file) = @_;
- my $patch = open_pipe("git-diff-tree", "-M50", "-r","--name-status", "-z","$rev")
- or die "Failed to exec git-diff: $!";
+ my $patch = $repo->command_output_pipe('diff-tree', '-M50', '-r', '--name-status', '-z', $rev);
local $/ = "\0";
my %bound;
@@ -227,7 +224,7 @@ sub find_parent_renames {
}
}
}
- close($patch);
+ $repo->command_close_pipe($patch);
return \%bound;
}
@@ -236,14 +233,9 @@ sub find_parent_renames {
sub git_find_parent {
my ($rev, $filename) = @_;
- my $revparent = open_pipe("git-rev-list","--remove-empty", "--parents","--max-count=1","$rev","--",$filename)
- or die "Failed to open git-rev-list to find a single parent: $!";
-
- my $parentline = <$revparent>;
- chomp $parentline;
- my ($revfound,$parent) = split m/\s+/, $parentline;
-
- close($revparent);
+ my $parentline = $repo->command_oneline('rev-list', '--remove-empty',
+ '--parents', '--max-count=1', $rev, '--', $filename);
+ my ($revfound, $parent) = split m/\s+/, $parentline;
return $parent;
}
@@ -254,13 +246,13 @@ # Record the commit information that res
sub git_diff_parse {
my ($parent, $rev, %revinfo) = @_;
- my $diff = open_pipe("git-diff-tree","-M","-p",$rev,$parent,"--",
- $revs{$rev}{'filename'}, $revs{$parent}{'filename'})
- or die "Failed to call git-diff for annotation: $!";
+ my $diff = $repo->command_output_pipe('diff-tree', '-M', '-p',
+ $rev, $parent, '--',
+ $revs{$rev}{'filename'}, $revs{$parent}{'filename'});
_git_diff_parse($diff, $parent, $rev, %revinfo);
- close($diff);
+ $repo->command_close_pipe($diff);
}
sub _git_diff_parse {
@@ -351,36 +343,25 @@ sub git_cat_file {
my $blob = git_ls_tree($rev, $filename);
die "Failed to find a blob for $filename in rev $rev\n" if !defined $blob;
- my $catfile = open_pipe("git","cat-file", "blob", $blob)
- or die "Failed to git-cat-file blob $blob (rev $rev, file $filename): " . $!;
-
- my @lines;
- while(<$catfile>) {
- chomp;
- push @lines, $_;
- }
- close($catfile);
-
+ my @lines = split(/\n/, $repo->get_object('blob', $blob));
+ pop @lines unless $lines[$#lines]; # Trailing newline
return @lines;
}
sub git_ls_tree {
my ($rev, $filename) = @_;
- my $lstree = open_pipe("git","ls-tree",$rev,$filename)
- or die "Failed to call git ls-tree: $!";
-
+ my $lstree = $repo->command_output_pipe('ls-tree', $rev, $filename);
my ($mode, $type, $blob, $tfilename);
while(<$lstree>) {
chomp;
($mode, $type, $blob, $tfilename) = split(/\s+/, $_, 4);
last if ($tfilename eq $filename);
}
- close($lstree);
+ $repo->command_close_pipe($lstree);
return $blob if ($tfilename eq $filename);
die "git-ls-tree failed to find blob for $filename";
-
}
@@ -396,25 +377,17 @@ sub claim_line {
sub git_commit_info {
my ($rev) = @_;
- my $commit = open_pipe("git-cat-file", "commit", $rev)
- or die "Failed to call git-cat-file: $!";
+ my $commit = $repo->get_object('commit', $rev);
my %info;
- while(<$commit>) {
- chomp;
- last if (length $_ == 0);
-
- if (m/^author (.*) <(.*)> (.*)$/) {
- $info{'author'} = $1;
- $info{'author_email'} = $2;
- $info{'author_date'} = $3;
- } elsif (m/^committer (.*) <(.*)> (.*)$/) {
- $info{'committer'} = $1;
- $info{'committer_email'} = $2;
- $info{'committer_date'} = $3;
+ while ($commit =~ /(.*?)\n/g) {
+ my $line = $1;
+ if ($line =~ s/^author //) {
+ @info{'author', 'author_email', 'author_date'} = $repo->ident($line);
+ } elsif ($line =~ s/^committer//) {
+ @info{'committer', 'committer_email', 'committer_date'} = $repo->ident($line);
}
}
- close($commit);
return %info;
}
@@ -432,81 +405,3 @@ sub format_date {
my $t = $timestamp + $minutes * 60;
return strftime("%Y-%m-%d %H:%M:%S " . $timezone, gmtime($t));
}
-
-# Copied from git-send-email.perl - We need a Git.pm module..
-sub gitvar {
- my ($var) = @_;
- my $fh;
- my $pid = open($fh, '-|');
- die "$!" unless defined $pid;
- if (!$pid) {
- exec('git-var', $var) or die "$!";
- }
- my ($val) = <$fh>;
- close $fh or die "$!";
- chomp($val);
- return $val;
-}
-
-sub gitvar_name {
- my ($name) = @_;
- my $val = gitvar($name);
- my @field = split(/\s+/, $val);
- return join(' ', @field[0...(@field-4)]);
-}
-
-sub open_pipe {
- if ($^O eq '##INSERT_ACTIVESTATE_STRING_HERE##') {
- return open_pipe_activestate(@_);
- } else {
- return open_pipe_normal(@_);
- }
-}
-
-sub open_pipe_activestate {
- tie *fh, "Git::ActiveStatePipe", @_;
- return *fh;
-}
-
-sub open_pipe_normal {
- my (@execlist) = @_;
-
- my $pid = open my $kid, "-|";
- defined $pid or die "Cannot fork: $!";
-
- unless ($pid) {
- exec @execlist;
- die "Cannot exec @execlist: $!";
- }
-
- return $kid;
-}
-
-package Git::ActiveStatePipe;
-use strict;
-
-sub TIEHANDLE {
- my ($class, @params) = @_;
- my $cmdline = join " ", @params;
- my @data = qx{$cmdline};
- bless { i => 0, data => \@data }, $class;
-}
-
-sub READLINE {
- my $self = shift;
- if ($self->{i} >= scalar @{$self->{data}}) {
- return undef;
- }
- return $self->{'data'}->[ $self->{i}++ ];
-}
-
-sub CLOSE {
- my $self = shift;
- delete $self->{data};
- delete $self->{i};
-}
-
-sub EOF {
- my $self = shift;
- return ($self->{i} >= scalar @{$self->{data}});
-}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox