<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/git.git/t/t9700, branch ss/userdiff-update-csharp-java</title>
<subtitle>github.com: git/git.git
</subtitle>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/'/>
<entry>
<title>t9700: do not close STDERR</title>
<updated>2013-04-04T21:49:56+00:00</updated>
<author>
<name>Thomas Rast</name>
<email>trast@inf.ethz.ch</email>
</author>
<published>2013-04-04T20:41:42+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=a749c0bbef068af339ea1ac8843f8ca307b3dd35'/>
<id>a749c0bbef068af339ea1ac8843f8ca307b3dd35</id>
<content type='text'>
Much like the previous patch, this triggered an unrelated bug.
Closing STDERR is not worth it anyway, as we risk writing die() and
such to random files that happen to be subsequently opened on FD 2.
Don't do it.

Signed-off-by: Thomas Rast &lt;trast@inf.ethz.ch&gt;
Reviewed-by: Jonathan Nieder &lt;jrnieder@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Much like the previous patch, this triggered an unrelated bug.
Closing STDERR is not worth it anyway, as we risk writing die() and
such to random files that happen to be subsequently opened on FD 2.
Don't do it.

Signed-off-by: Thomas Rast &lt;trast@inf.ethz.ch&gt;
Reviewed-by: Jonathan Nieder &lt;jrnieder@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>git-config: do not complain about duplicate entries</title>
<updated>2012-10-24T07:36:55+00:00</updated>
<author>
<name>Jeff King</name>
<email>peff@peff.net</email>
</author>
<published>2012-10-23T20:52:44+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=00b347d3aa094948d58dd1303aef7ba97ff09519'/>
<id>00b347d3aa094948d58dd1303aef7ba97ff09519</id>
<content type='text'>
If git-config is asked for a single value, it will complain
and exit with an error if it finds multiple instances of
that value. This is unlike the usual internal config
parsing, however, which will generally overwrite previous
values, leaving only the final one. For example:

  [set a multivar]
  $ git config user.email one@example.com
  $ git config --add user.email two@example.com

  [use the internal parser to fetch it]
  $ git var GIT_AUTHOR_IDENT
  Your Name &lt;two@example.com&gt; ...

  [use git-config to fetch it]
  $ git config user.email
  one@example.com
  error: More than one value for the key user.email: two@example.com

This overwriting behavior is critical for the regular
parser, which starts with the lowest-priority file (e.g.,
/etc/gitconfig) and proceeds to the highest-priority file
($GIT_DIR/config). Overwriting yields the highest priority
value at the end.

Git-config solves this problem by implementing its own
parsing. It goes from highest to lowest priorty, but does
not proceed to the next file if it has seen a value.

So in practice, this distinction never mattered much,
because it only triggered for values in the same file. And
there was not much point in doing that; the real value is in
overwriting values from lower-priority files.

However, this changed with the implementation of config
include files. Now we might see an include overriding a
value from the parent file, which is a sensible thing to do,
but git-config will flag as a duplication.

This patch drops the duplicate detection for git-config and
switches to a pure-overwrite model (for the single case;
--get-all can still be used if callers want to do something
more fancy).

As is shown by the modifications to the test suite, this is
a user-visible change in behavior. An alternative would be
to just change the include case, but this is much cleaner
for a few reasons:

  1. If you change the include case, then to what? If you
     just stop parsing includes after getting a value, then
     you will get a _different_ answer than the regular
     config parser (you'll get the first value instead of
     the last value). So you'd want to implement overwrite
     semantics anyway.

  2. Even though it is a change in behavior for git-config,
     it is bringing us in line with what the internal
     parsers already do.

  3. The file-order reimplementation is the only thing
     keeping us from sharing more code with the internal
     config parser, which will help keep differences to a
     minimum.

Going under the assumption that the primary purpose of
git-config is to behave identically to how git's internal
parsing works, this change can be seen as a bug-fix.

Signed-off-by: Jeff King &lt;peff@peff.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If git-config is asked for a single value, it will complain
and exit with an error if it finds multiple instances of
that value. This is unlike the usual internal config
parsing, however, which will generally overwrite previous
values, leaving only the final one. For example:

  [set a multivar]
  $ git config user.email one@example.com
  $ git config --add user.email two@example.com

  [use the internal parser to fetch it]
  $ git var GIT_AUTHOR_IDENT
  Your Name &lt;two@example.com&gt; ...

  [use git-config to fetch it]
  $ git config user.email
  one@example.com
  error: More than one value for the key user.email: two@example.com

This overwriting behavior is critical for the regular
parser, which starts with the lowest-priority file (e.g.,
/etc/gitconfig) and proceeds to the highest-priority file
($GIT_DIR/config). Overwriting yields the highest priority
value at the end.

Git-config solves this problem by implementing its own
parsing. It goes from highest to lowest priorty, but does
not proceed to the next file if it has seen a value.

So in practice, this distinction never mattered much,
because it only triggered for values in the same file. And
there was not much point in doing that; the real value is in
overwriting values from lower-priority files.

However, this changed with the implementation of config
include files. Now we might see an include overriding a
value from the parent file, which is a sensible thing to do,
but git-config will flag as a duplication.

This patch drops the duplicate detection for git-config and
switches to a pure-overwrite model (for the single case;
--get-all can still be used if callers want to do something
more fancy).

As is shown by the modifications to the test suite, this is
a user-visible change in behavior. An alternative would be
to just change the include case, but this is much cleaner
for a few reasons:

  1. If you change the include case, then to what? If you
     just stop parsing includes after getting a value, then
     you will get a _different_ answer than the regular
     config parser (you'll get the first value instead of
     the last value). So you'd want to implement overwrite
     semantics anyway.

  2. Even though it is a change in behavior for git-config,
     it is bringing us in line with what the internal
     parsers already do.

  3. The file-order reimplementation is the only thing
     keeping us from sharing more code with the internal
     config parser, which will help keep differences to a
     minimum.

Going under the assumption that the primary purpose of
git-config is to behave identically to how git's internal
parsing works, this change can be seen as a bug-fix.

Signed-off-by: Jeff King &lt;peff@peff.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Add simple test for Git::config_path() in t/t9700-perl-git.sh</title>
<updated>2011-10-21T21:34:08+00:00</updated>
<author>
<name>Jakub Narebski</name>
<email>jnareb@gmail.com</email>
</author>
<published>2011-10-21T18:42:44+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=cb9c9df37acf5ff8a452b5fe2eaf7ad6ff8bfb72'/>
<id>cb9c9df37acf5ff8a452b5fe2eaf7ad6ff8bfb72</id>
<content type='text'>
Tests "~/foo" path expansion and multiple values.

Signed-off-by: Jakub Narebski &lt;jnareb@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Tests "~/foo" path expansion and multiple values.

Signed-off-by: Jakub Narebski &lt;jnareb@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>perl: command_bidi_pipe() method should set-up git environmens</title>
<updated>2011-02-14T23:28:13+00:00</updated>
<author>
<name>Masatake Osanai</name>
<email>unpush@gmail.com</email>
</author>
<published>2011-02-14T22:13:04+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=48d9e6ae4bcb6fd08562595aed47bef7326ec144'/>
<id>48d9e6ae4bcb6fd08562595aed47bef7326ec144</id>
<content type='text'>
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-&gt;repository(Directory =&gt; '/some/where/else');
    my ($pid, $in, $out, $ctx) =
    $repo-&gt;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 &lt;unpush@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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-&gt;repository(Directory =&gt; '/some/where/else');
    my ($pid, $in, $out, $ctx) =
    $repo-&gt;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 &lt;unpush@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>perl: bump the required Perl version to 5.8 from 5.6.[21]</title>
<updated>2010-09-27T19:37:41+00:00</updated>
<author>
<name>Ævar Arnfjörð Bjarmason</name>
<email>avarab@gmail.com</email>
</author>
<published>2010-09-24T20:00:52+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=d48b28418355ef41a9501eb28a82ec0b69e62a17'/>
<id>d48b28418355ef41a9501eb28a82ec0b69e62a17</id>
<content type='text'>
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 &lt;$fh&gt;;
    }

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 &lt;avarab@gmail.com&gt;
Acked-by: Tor Arntsen &lt;tor@spacetec.no&gt;
Acked-by: Randal L. Schwartz &lt;merlyn@stonehenge.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;$fh&gt;;
    }

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 &lt;avarab@gmail.com&gt;
Acked-by: Tor Arntsen &lt;tor@spacetec.no&gt;
Acked-by: Randal L. Schwartz &lt;merlyn@stonehenge.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>t/t9700/test.pl: don't access private object members, use public access methods</title>
<updated>2010-06-29T16:32:56+00:00</updated>
<author>
<name>Brandon Casey</name>
<email>drafnel@gmail.com</email>
</author>
<published>2010-06-28T22:51:02+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=15eeb6e921a08f2565192701c6b1ee5f1cbe9753'/>
<id>15eeb6e921a08f2565192701c6b1ee5f1cbe9753</id>
<content type='text'>
This test is accessing private object members of the Test::More and
Test::Builder objects.  Older versions of Test::More did not implement
these variables using a hash.

My system complains as follows:

   Can't coerce array into hash at &lt;snip&gt;/t/t9700/test.pl line 13.
   BEGIN failed--compilation aborted at &lt;snip&gt;/t/t9700/test.pl line 15.

There are public access methods available for retrieving and setting these
variables, so let's use them instead.

Signed-off-by: Brandon Casey &lt;casey@nrlssc.navy.mil&gt;
Acked-by: Ævar Arnfjörð Bjarmason &lt;avarab@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This test is accessing private object members of the Test::More and
Test::Builder objects.  Older versions of Test::More did not implement
these variables using a hash.

My system complains as follows:

   Can't coerce array into hash at &lt;snip&gt;/t/t9700/test.pl line 13.
   BEGIN failed--compilation aborted at &lt;snip&gt;/t/t9700/test.pl line 15.

There are public access methods available for retrieving and setting these
variables, so let's use them instead.

Signed-off-by: Brandon Casey &lt;casey@nrlssc.navy.mil&gt;
Acked-by: Ævar Arnfjörð Bjarmason &lt;avarab@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>t9700: Use Test::More-&gt;builder, not $Test::Builder::Test</title>
<updated>2010-06-27T17:24:55+00:00</updated>
<author>
<name>Ævar Arnfjörð Bjarmason</name>
<email>avarab@gmail.com</email>
</author>
<published>2010-06-26T12:42:41+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=635155fa3d825570080d727245a76e666bbae145'/>
<id>635155fa3d825570080d727245a76e666bbae145</id>
<content type='text'>
$Test::Builder::Test was only made into an `our' variable in 0.94
released in September 2009, older distros are more likely to have 0.92
or earlier. Use the singleton Test::More-&gt;builder constructor instead.

The exit() call was also unportable to &lt;0.94. Just output a meaningful
exit code if the -&gt;is_passing method exists. The t9700-perl-git.sh
test only cares about stderr output, so this doesn't affect test
results when using older Test::More modules.

Signed-off-by: Ævar Arnfjörð Bjarmason &lt;avarab@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
$Test::Builder::Test was only made into an `our' variable in 0.94
released in September 2009, older distros are more likely to have 0.92
or earlier. Use the singleton Test::More-&gt;builder constructor instead.

The exit() call was also unportable to &lt;0.94. Just output a meaningful
exit code if the -&gt;is_passing method exists. The t9700-perl-git.sh
test only cares about stderr output, so this doesn't affect test
results when using older Test::More modules.

Signed-off-by: Ævar Arnfjörð Bjarmason &lt;avarab@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test-lib: Make the test_external_* functions TAP-aware</title>
<updated>2010-06-25T17:06:30+00:00</updated>
<author>
<name>Ævar Arnfjörð Bjarmason</name>
<email>avarab@gmail.com</email>
</author>
<published>2010-06-24T17:44:46+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=d998bd4ab6714051ad122f89489ddbca2bb3367b'/>
<id>d998bd4ab6714051ad122f89489ddbca2bb3367b</id>
<content type='text'>
Before TAP we just ran the Perl test and assumed that it failed if
nothing was printed on STDERR. Continue doing that, but introduce a
`test_external_has_tap' variable which tests can set to indicate that
they're outputting TAP.

If it's set we won't output a test plan, but trust the external test
to do so. That way we can make external tests work with a TAP harness,
but still maintain compatibility with test-lib's own way of tracking
tests through the test-results directory.

Signed-off-by: Ævar Arnfjörð Bjarmason &lt;avarab@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before TAP we just ran the Perl test and assumed that it failed if
nothing was printed on STDERR. Continue doing that, but introduce a
`test_external_has_tap' variable which tests can set to indicate that
they're outputting TAP.

If it's set we won't output a test plan, but trust the external test
to do so. That way we can make external tests work with a TAP harness,
but still maintain compatibility with test-lib's own way of tracking
tests through the test-results directory.

Signed-off-by: Ævar Arnfjörð Bjarmason &lt;avarab@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>t9700-perl-git.sh: Fix a test failure on Cygwin</title>
<updated>2009-11-20T07:01:09+00:00</updated>
<author>
<name>Ramsay Jones</name>
<email>ramsay@ramsay1.demon.co.uk</email>
</author>
<published>2009-11-19T18:41:20+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=81f40262a491cd0429ca88476365a7ccedb78684'/>
<id>81f40262a491cd0429ca88476365a7ccedb78684</id>
<content type='text'>
The t/t9700/test.pl script uses method invocation syntax when
using the Cwd module to determine the current working directory.
This fails on cygwin, since cygwin perl specifically checks for
any arguments to the cwd() function and croak()'s with the message
"Usage: Cwd::cwd()". (In perl v5.8.8 distribution, see the file
perl-5.8.8/cygwin/cygwin.c lines 139-157)

In order to avoid the problem, we replace the method invocation
syntax with a simple function call.

Signed-off-by: Ramsay Jones &lt;ramsay@ramsay1.demon.co.uk&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The t/t9700/test.pl script uses method invocation syntax when
using the Cwd module to determine the current working directory.
This fails on cygwin, since cygwin perl specifically checks for
any arguments to the cwd() function and croak()'s with the message
"Usage: Cwd::cwd()". (In perl v5.8.8 distribution, see the file
perl-5.8.8/cygwin/cygwin.c lines 139-157)

In order to avoid the problem, we replace the method invocation
syntax with a simple function call.

Signed-off-by: Ramsay Jones &lt;ramsay@ramsay1.demon.co.uk&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Git.pm: Always set Repository to absolute path if autodetecting</title>
<updated>2009-05-09T15:25:55+00:00</updated>
<author>
<name>Frank Lichtenheld</name>
<email>flichtenheld@astaro.com</email>
</author>
<published>2009-05-07T13:41:28+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=fe53bbc9bebb853f97f0da3f63f7fca5774e3f95'/>
<id>fe53bbc9bebb853f97f0da3f63f7fca5774e3f95</id>
<content type='text'>
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 &lt;flichtenheld@astaro.com&gt;
Acked-by: Petr Baudis &lt;pasky@suse.cz&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;flichtenheld@astaro.com&gt;
Acked-by: Petr Baudis &lt;pasky@suse.cz&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
