Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Petr Baudis <pasky@suse.cz>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] [RFC] Introduce Git.pm
Date: Wed, 21 Jun 2006 18:03:02 -0700	[thread overview]
Message-ID: <7v64iuxard.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20060622003546.17760.23089.stgit@machine.or.cz> (Petr Baudis's message of "Thu, 22 Jun 2006 02:35:46 +0200")

Petr Baudis <pasky@suse.cz> writes:

> Currently Git.pm just wraps up exec()s of Git commands, but even that
> is not trivial to get right and various Git perl scripts do it in
> various inconsistent ways. And things will get much more interesting
> when we get to XS-izing libgit.

We would probably need some moderate to major surgery before
doing that depending on which parts.  Worrisome are object layer
that holds onto parsed objects and keeps flag bits from the
previous runs, and lockfile that are cleaned up via atexit() --
there may be others.

> @@ -618,6 +622,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
>  	@FLAGS='$(TRACK_CFLAGS)'; \
>  	    if test x"$$FLAGS" != x"`cat GIT-CFLAGS 2>/dev/null`" ; then \
>  		echo 1>&2 "    * new build flags or prefix"; \
> +		echo 1>&2 "    * $$FLAGS != `cat GIT-CFLAGS 2>/dev/null`"; \
>  		echo "$$FLAGS" >GIT-CFLAGS; \
>              fi
>  

Offtopic; do people mind if we drop $GIT_VERSION from
TRACK_CFLAGS?  Every time I switch branches or make a new commit
it ends up rebuilding everything needlessly.

>  sub current_branch {
> -	my ($bra) = qx{git-symbolic-ref HEAD};
> +	my ($bra) = $repo->generic_oneline('symbolic-ref', 'HEAD');
>  	chomp($bra);
>  	$bra =~ s|^refs/heads/||;
>  	if ($bra ne 'master') {

Your *_oneline chomps so chomp($bra) is not needed anymore, I think.

In any case, this is an excellent move to clean things up.
Various implementations of qx{} will be all in one place so
ActiveState folks would have easier time adjusting things to
their environment.

> +require Exporter;

Not "use"?

> +# Methods which can be called as standalone functions as well:
> +@EXPORT_OK = qw(generic generic_oneval generic_vocal);

I am not sure generic_xxx is a good name.  Perhaps command_xxx?

Also as you say in the comment, "vocal" sounds a bit funny.
I wonder if we can use wantarray to detect the case where the
caller wants _no_ value, and do the "not piping" optimization in
that case.

  reply	other threads:[~2006-06-22  1:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-22  0:35 [PATCH] [RFC] Introduce Git.pm Petr Baudis
2006-06-22  1:03 ` Junio C Hamano [this message]
2006-06-22  7:18   ` Alex Riesen
2006-06-22 19:37   ` Petr Baudis
2006-06-22  2:31 ` Eric Wong
2006-06-22  8:07 ` Jakub Narebski
2006-06-22  9:01 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v64iuxard.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox