delta/git.git/perl, branch rs/diff-whole-function

perl: command_bidi_pipe() method should set-up git environmens

2011-02-14T23:28:13+00:00

When command_input_pipe and command_output_pipe are used as a
method of a Git::repository instance, they eventually call into
_cmd_exec method that sets up the execution environment such as
GIT_DIR, GIT_WORK_TREE environment variables and the current
working directory in the child process that interacts with the
repository.

command_bidi_pipe however didn't expect to be called as such, and
lacked all these set-up.  Because of this, a program that did this
did not work as expected:

    my $repo = Git->repository(Directory => '/some/where/else');
    my ($pid, $in, $out, $ctx) =
    $repo->command_bidi_pipe(qw(hash-object -w --stdin-paths));

This patch refactors the _cmd_exec into _setup_git_cmd_env that
sets up the execution environment, and makes _cmd_exec and
command_bidi_pipe to use it.

Note that unlike _cmd_exec that execv's a git command as an
external process, command_bidi_pipe is called from the main line
of control, and the execution environment needs to be restored
after open2() does its magic.

Signed-off-by: Masatake Osanai 
Signed-off-by: Junio C Hamano

perl: bump the required Perl version to 5.8 from 5.6.[21]

2010-09-27T19:37:41+00:00

Formalize our dependency on perl 5.8, bumped from 5.6.[12]. We already
used the three-arg form of open() which was introduced in 5.6.1, but
t/t9700/test.pl explicitly depended on 5.6.2.

However git-add--interactive.pl has been failing on the 5.6 line since
it was introduced in v1.5.0-rc0~12^2~2 back in 2006 due to this open
syntax:

    sub run_cmd_pipe {
           my $fh = undef;
           open($fh, '-|', @_) or die;
           return <$fh>;
    }

Which when executed dies on "Can't use an undefined value as
filehandle reference". Several of our tests also fail on 5.6 (even
more when compiled with NO_PERL_MAKEMAKER=1):

    t2016-checkout-patch.sh
    t3904-stash-patch.sh
    t3701-add-interactive.sh
    t7105-reset-patch.sh
    t7501-commit.sh
    t9700-perl-git.sh

Our code is bitrotting on 5.6 with no-one interested in fixing it, and
pinning us to such an ancient release of Perl is keeping us from using
useful features introduced in the 5.8 release.

The 5.6 series is now over 10 years old, and the 5.6.2 maintenance
release almost 7. 5.8 on the other hand is more than 8 years old.

All the modern Unix-like operating systems have now upgraded to it or
a later version, and 5.8 packages are available for old IRIX, AIX
Solaris and Tru64 systems.

Signed-off-by: Ævar Arnfjörð Bjarmason 
Acked-by: Tor Arntsen 
Acked-by: Randal L. Schwartz 
Signed-off-by: Junio C Hamano

perl/Makefile: Unset INSTALL_BASE when making perl.mak

2010-08-13T04:55:17+00:00

PREFIX and INSTALL_BASE are mutually exclusive. If both are supplied
by INSTALL_BASE being set in PERL_MM_OPT ExtUtils::MakeMaker will
produce an error:

    $ echo $PERL_MM_OPT
    INSTALL_BASE=/home/avar/perl5
    $ make -C perl  PERL_PATH='/usr/bin/perl' prefix='/home/avar' perl.mak
    make: Entering directory `/home/avar/g/git/perl'
    /usr/bin/perl Makefile.PL PREFIX='/home/avar'
    Only one of PREFIX or INSTALL_BASE can be given.  Not both.
    make: *** [perl.mak] Error 255
    make: Leaving directory `/home/avar/g/git/perl'

Change the perl Makefile to work around this by explicitly unsetting
INSTALL_BASE.

INSTALL_BASE is set in PERL_MM_OPT by e.g. the popular local::lib
package, from its documentation:

    eval $(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib 2>/dev/null)

Many other environments might also have set PERL_MM_OPT before
building Git. This change enables us to build in these environments.

Signed-off-by: Ævar Arnfjörð Bjarmason 
Signed-off-by: Junio C Hamano

Git.pm: better error message

2010-06-18T15:49:03+00:00

Provide the bad directory name alongside with $!

Note: $! is set if there is "No such file or directory",
but isn't set if the file exists but is not a directory.

Signed-off-by: Philippe Bruhat (BooK) 
Signed-off-by: Junio C Hamano

git-svn: support fetch with autocrlf on

2010-03-05T10:57:57+00:00

Before commit d3c9634e, performing a "git svn rebase" that fetched a
change containing CRLFs corrupted the git-svn meta-data. This was
worked around in d3c9634e by setting core.autocrlf to "false" in the
per-repo config when initing the clone. However, if the config
variable was later changed, the corruption would still occur.

This patch tries to fix it while allowing core.autocrlf to be
enabled, by disabling filters when when hashing.

git-svn is currently the only call-site for hash_and_insert_object
(apart from the test-suite), so changing it should be safe.

Signed-off-by: Erik Faye-Lund 
Acked-by: Eric Wong

Typofixes outside documentation area

2010-02-04T05:28:17+00:00

    begining -> beginning
    canonicalizations -> canonicalization
    comand -> command
    dewrapping -> unwrapping
    dirtyness -> dirtiness
    DISCLAMER -> DISCLAIMER
    explicitely -> explicitly
    feeded -> fed
    impiled -> implied
    madatory -> mandatory
    mimick -> mimic
    preceeding -> preceding
    reqeuest -> request
    substition -> substitution

Signed-off-by: Junio C Hamano

perl/Makefile.PL: detect MakeMaker versions incompatible with DESTDIR

2009-09-25T21:00:04+00:00

It appears that ExtUtils::MakeMaker versions older than 6.11 do not
implement the DESTDIR mechanism.  So add a test to the generated perl.mak
to detect when DESTDIR is used along with a too old ExtUtils::MakeMaker and
abort with a message suggesting the use of NO_PERL_MAKEMAKER.

Signed-off-by: Brandon Casey 
Signed-off-by: Shawn O. Pearce

pay attention to DESTDIR when building with NO_PERL_MAKEMAKER

2009-09-22T19:20:40+00:00

Building with prefix=/some/where and temporarily installing it to
elsewhere for tar'ing up is done with:

    make prefix=/some/where
    make prefix=/some/where DESTDIR=/else/where install

Make handcrafted perl/perl.mak without NO_PERL_MAKEMAKER honour DESTDIR.

Ancient ExtUtils::MakeMaker (pre 6.11?) has the same issue, but recent
versions of Perl ships with at leat 6.17; this patch does not address that
issue.

Signed-off-by: Junio C Hamano

Git.pm: Always set Repository to absolute path if autodetecting

2009-05-09T15:25:55+00:00

So far we only set it to absolute paths in some cases which lead
to problems like wc_chdir not working.

Signed-off-by: Frank Lichtenheld 
Acked-by: Petr Baudis 
Signed-off-by: Junio C Hamano

Git.pm: Set GIT_WORK_TREE if we set GIT_DIR

2009-05-09T15:25:55+00:00

Otherwise git will use the current directory as work tree which will
lead to unexpected results if we operate in sub directory of the
work tree.

Signed-off-by: Frank Lichtenheld 
Acked-by: Petr Baudis 
Signed-off-by: Junio C Hamano