Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)

2012-11-13 Thread Ramsay Jones 
Jeff King wrote:
 On Sat, Nov 10, 2012 at 06:33:38PM +, Ramsay Jones wrote:
 
 We should probably wrap it. I'm planning to queue this on top of Chris's
 patch:

 Unfortunately, I haven't had time yet to test this patch. (Early this week, I
 went into hospital for a minor surgical procedure - I have not yet fully
 recovered). The patch looks good and I don't anticipate any problems. I will
 hopefully test it soon (I see it's in pu now) and let you know.
 
 Thanks. I merged it to next on Friday, so we will see if anybody
 screams. But please take your time and recover. Git will wait. :)

I have tested this patch and, as expected, it fixes things up for me.
(To be more precise: the current next branch works, but if I revert
commit c2b3af05, then t9604-cvsimport-timestamps.sh fails in the
same way as before!)

Thanks!

ATB,
Ramsay Jones


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)

2012-11-10 Thread Ramsay Jones 
Jeff King wrote:
 On Fri, Nov 02, 2012 at 09:33:14PM +, Ramsay Jones wrote:
 
 (Linux is my main platform, but I like to keep cygwin working because it has
 kept me sane on Windows ever since (about) 1995 ...)
 Stranger in a strange land ;-)
 
 I used a different trick around the same time to keep me sane from
 Windows, but I think it involved dd and /dev/zero...

;-) That's a solution I would have been keen to try, but my employer
at the time would not have liked that idea ...


 This patch fixes the test for me.
 
 Great. I was guessing blindly when I wrote it, but having seen the perl
 bug above, it all makes sense.
 
 We should probably wrap it. I'm planning to queue this on top of Chris's
 patch:

Unfortunately, I haven't had time yet to test this patch. (Early this week, I
went into hospital for a minor surgical procedure - I have not yet fully
recovered). The patch looks good and I don't anticipate any problems. I will
hopefully test it soon (I see it's in pu now) and let you know.

[snip patch]

ATB,
Ramsay Jones


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)

2012-11-04 Thread Jeff King 
On Fri, Nov 02, 2012 at 09:33:14PM +, Ramsay Jones wrote:

  I wonder if Ramsay has an older perl that does not do this special
  hackery right. I'll see if I can dig up where it first appeared.
 
 Hmm, sorry for not specifying this upfront, but this failure is on Linux. ;-)

Ah, that's helpful to know.

 (Linux is my main platform, but I like to keep cygwin working because it has
 kept me sane on Windows ever since (about) 1995 ...)
 Stranger in a strange land ;-)

I used a different trick around the same time to keep me sane from
Windows, but I think it involved dd and /dev/zero...

 I'm using perl v5.8.8 on Linux.

Yeah, that is the problem. Calling localtime_r repeatedly while changing
the timezone does not work on some platforms:

  https://rt.perl.org/rt3/Public/Bug/Display.html?id=26136

The fix (to call tzset each time) went into perl 5.10.0.

  Ramsay, what happens with this patch on top?
 
 This patch fixes the test for me.

Great. I was guessing blindly when I wrote it, but having seen the perl
bug above, it all makes sense.

We should probably wrap it. I'm planning to queue this on top of Chris's
patch:

-- 8 --
Subject: [PATCH] cvsimport: work around perl tzset issue

On many platforms, the first invocation of localtime_r will
check $TZ in the environment, but subsequent invocations
will use a cache value. That means that setting $ENV{TZ} in
the middle of the program may or may not have an effect on
later calls to localtime.  Perl 5.10.0 and later handles
this automatically for us, but we try to remain portable
back to 5.8. Work around it by calling tzset ourselves.

Signed-off-by: Jeff King p...@peff.net
---
 git-cvsimport.perl | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index ceb119d..0a31ebd 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -24,11 +24,11 @@ use File::Basename qw(basename dirname);
 use Time::Local;
 use IO::Socket;
 use IO::Pipe;
-use POSIX qw(strftime dup2 ENOENT);
+use POSIX qw(strftime tzset dup2 ENOENT);
 use IPC::Open2;
 
 $SIG{'PIPE'}=IGNORE;
-$ENV{'TZ'}=UTC;
+set_timezone('UTC');
 
 our 
($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, 
$opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r, $opt_R);
 my (%conv_author_name, %conv_author_email, %conv_author_tz);
@@ -99,6 +99,15 @@ sub write_author_info($) {
close ($f);
 }
 
+# Versions of perl before 5.10.0 may not automatically check $TZ each
+# time localtime is run (most platforms will do so only the first time).
+# We can work around this by using tzset() to update the internal
+# variable whenever we change the environment.
+sub set_timezone {
+   $ENV{TZ} = shift;
+   tzset();
+}
+
 # convert getopts specs for use by git config
 my %longmap = (
'A:' = 'authors-file',
@@ -854,9 +863,9 @@ sub commit {
}
}
 
-   $ENV{'TZ'}=$author_tz;
+   set_timezone($author_tz);
my $commit_date = strftime(%s %z, localtime($date));
-   $ENV{'TZ'}=UTC;
+   set_timezone('UTC');
$ENV{GIT_AUTHOR_NAME} = $author_name;
$ENV{GIT_AUTHOR_EMAIL} = $author_email;
$ENV{GIT_AUTHOR_DATE} = $commit_date;
-- 
1.8.0.207.gdf2154c

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)

2012-11-02 Thread Jeff King 
On Thu, Nov 01, 2012 at 08:12:20PM -0500, Chris Rorvick wrote:

  Just FYI, t9604-cvsimport-timestamps.sh is still failing for me.
 
  I haven't spent too long on this yet, but I had hoped that setting
  TZ would sidestep any DST issues. (I have downloaded new tzdata, but
  have yet to install - actually I don't really want to!). It is not
  clear from the tzset manpage what happens if you use the DST format
  for TZ, but you don't provide the start/end date for DST, which is
  what this test is doing.
 
  Perhaps the test should use the non-DST format? e.g. TZ=CST6 git ...
  Does the test really care about DST? (*if* that is indeed the problem).
 
 It actually looks like your TZ database is fine and the problem is
 with the conversion to a struct tm.  In each case, the time is
 localized to the previous TZ value while the offset for the current TZ
 value.  For example, look at the first commit in the first test.  It
 converted the timestamp to 18:00 (CST6) while all the rest came
 through as expected.I suspect the previous version of cvsimport
 would exhibit similar behavior with the first imported commit.  What
 is your platform?

Yeah, I think that is it. IIRC, Ramsay is on cygwin, and I noticed this
in perl 5.16's POSIX.xs:

  #ifdef WIN32

  /*
   * (1) The CRT maintains its own copy of the environment, separate from
   * the Win32API copy.
   *
   * (2) CRT getenv() retrieves from this copy. CRT putenv() updates this
   * copy, and then calls SetEnvironmentVariableA() to update the Win32API
   * copy.
   *
   * (3) win32_getenv() and win32_putenv() call GetEnvironmentVariableA() and
   * SetEnvironmentVariableA() directly, bypassing the CRT copy of the
   * environment.
   *
   * (4) The CRT strftime() %Z implementation calls __tzset(). That
   * calls CRT tzset(), but only the first time it is called, and in turn
   * that uses CRT getenv(TZ) to retrieve the timezone info from the CRT
   * local copy of the environment and hence gets the original setting as
   * perl never updates the CRT copy when assigning to $ENV{TZ}.
   *
   * Therefore, we need to retrieve the value of $ENV{TZ} and call CRT
   * putenv() to update the CRT copy of the environment (if it is different)
   * whenever we're about to call tzset().
   [...]

I wonder if Ramsay has an older perl that does not do this special
hackery right. I'll see if I can dig up where it first appeared.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)

2012-11-02 Thread Jeff King 
On Fri, Nov 02, 2012 at 05:43:00AM -0400, Jeff King wrote:

 Yeah, I think that is it. IIRC, Ramsay is on cygwin, and I noticed this
 in perl 5.16's POSIX.xs:

 [...]
* (4) The CRT strftime() %Z implementation calls __tzset(). That
* calls CRT tzset(), but only the first time it is called, and in turn
* that uses CRT getenv(TZ) to retrieve the timezone info from the CRT
* local copy of the environment and hence gets the original setting as
* perl never updates the CRT copy when assigning to $ENV{TZ}.
 [...]
 I wonder if Ramsay has an older perl that does not do this special
 hackery right. I'll see if I can dig up where it first appeared.

It looks like that code went into perl 5.11.

I wonder, even with this fix, though, if we need to be calling tzset to
reliably update from the environment. It sounds like it _should_ happen
automatically, except that if the CRT is calling the internal tzset, it
would not do the perl grab from $ENV magic. Calling tzset would make
sure the internal TZ is up to date.

Ramsay, what happens with this patch on top?

diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index ceb119d..4c44050 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -24,11 +24,12 @@ use File::Basename qw(basename dirname);
 use Time::Local;
 use IO::Socket;
 use IO::Pipe;
-use POSIX qw(strftime dup2 ENOENT);
+use POSIX qw(strftime tzset dup2 ENOENT);
 use IPC::Open2;
 
 $SIG{'PIPE'}=IGNORE;
 $ENV{'TZ'}=UTC;
+tzset();
 
 our 
($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, 
$opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r, $opt_R);
 my (%conv_author_name, %conv_author_email, %conv_author_tz);
@@ -855,8 +856,10 @@ sub commit {
}
 
$ENV{'TZ'}=$author_tz;
+   tzset();
my $commit_date = strftime(%s %z, localtime($date));
$ENV{'TZ'}=UTC;
+   tzset();
$ENV{GIT_AUTHOR_NAME} = $author_name;
$ENV{GIT_AUTHOR_EMAIL} = $author_email;
$ENV{GIT_AUTHOR_DATE} = $commit_date;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)

2012-11-02 Thread Ramsay Jones 
Jeff King wrote:
 On Fri, Nov 02, 2012 at 05:43:00AM -0400, Jeff King wrote:
 
 Yeah, I think that is it. IIRC, Ramsay is on cygwin, and I noticed this
 in perl 5.16's POSIX.xs:

 [...]
* (4) The CRT strftime() %Z implementation calls __tzset(). That
* calls CRT tzset(), but only the first time it is called, and in turn
* that uses CRT getenv(TZ) to retrieve the timezone info from the CRT
* local copy of the environment and hence gets the original setting as
* perl never updates the CRT copy when assigning to $ENV{TZ}.
 [...]
 I wonder if Ramsay has an older perl that does not do this special
 hackery right. I'll see if I can dig up where it first appeared.

Hmm, sorry for not specifying this upfront, but this failure is on Linux. ;-)
(Linux is my main platform, but I like to keep cygwin working because it has
kept me sane on Windows ever since (about) 1995 ...)
Stranger in a strange land ;-)

This test is skipped on cygwin because I don't have cvs (or cvsps) installed
on cygwin. (I have cvs-1.11.1p1.tar.gz and cvsps-2.2b1.tar.gz lying around
on cygwin, so I could probably build them from source and do some testing if
you would like me too. Just let me know.)

This test is skipped on MinGW because cvsps is not installed. (I have just
tried building cvsps, but there are compilation errors ...).

I'm using perl v5.8.8 on Linux.

 It looks like that code went into perl 5.11.
 
 I wonder, even with this fix, though, if we need to be calling tzset to
 reliably update from the environment. It sounds like it _should_ happen
 automatically, except that if the CRT is calling the internal tzset, it
 would not do the perl grab from $ENV magic. Calling tzset would make
 sure the internal TZ is up to date.
 
 Ramsay, what happens with this patch on top?

This patch fixes the test for me.

Thanks!

ATB,
Ramsay Jones

 diff --git a/git-cvsimport.perl b/git-cvsimport.perl
 index ceb119d..4c44050 100755
 --- a/git-cvsimport.perl
 +++ b/git-cvsimport.perl
 @@ -24,11 +24,12 @@ use File::Basename qw(basename dirname);
  use Time::Local;
  use IO::Socket;
  use IO::Pipe;
 -use POSIX qw(strftime dup2 ENOENT);
 +use POSIX qw(strftime tzset dup2 ENOENT);
  use IPC::Open2;
  
  $SIG{'PIPE'}=IGNORE;
  $ENV{'TZ'}=UTC;
 +tzset();
  
  our 
 ($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P,
  $opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r, $opt_R);
  my (%conv_author_name, %conv_author_email, %conv_author_tz);
 @@ -855,8 +856,10 @@ sub commit {
   }
  
   $ENV{'TZ'}=$author_tz;
 + tzset();
   my $commit_date = strftime(%s %z, localtime($date));
   $ENV{'TZ'}=UTC;
 + tzset();
   $ENV{GIT_AUTHOR_NAME} = $author_name;
   $ENV{GIT_AUTHOR_EMAIL} = $author_email;
   $ENV{GIT_AUTHOR_DATE} = $commit_date;
 .
 

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)

2012-11-01 Thread Ramsay Jones 
Jeff King wrote:
 What's cooking in git.git (Oct 2012, #09; Mon, 29)
 --
 

[snip]

 * cr/cvsimport-local-zone (2012-10-16) 1 commit
  - git-cvsimport: allow author-specific timezones
 
  Allows cvsimport to read per-author timezone from the author info
  file.
 
  Will merge to 'next'.

Just FYI, t9604-cvsimport-timestamps.sh is still failing for me.

I haven't spent too long on this yet, but I had hoped that setting
TZ would sidestep any DST issues. (I have downloaded new tzdata, but
have yet to install - actually I don't really want to!). It is not
clear from the tzset manpage what happens if you use the DST format
for TZ, but you don't provide the start/end date for DST, which is
what this test is doing.

Perhaps the test should use the non-DST format? e.g. TZ=CST6 git ...
Does the test really care about DST? (*if* that is indeed the problem).

Also: Note that the first test calls git-cvsimport twice, first *with*
TZ set then again without; I suspect a cut/paste editing error.

I have added the output of ./t9604-cvsimport-timestamps.sh -v below.

ATB,
Ramsay Jones



ramsay@ramsay-laptop:$ ./t9604-cvsimport-timestamps.sh -v
Initialized empty Git repository in /home/ramsay/git/t/trash 
directory.t9604-cvsimport-timestamps/.git/
expecting success: 

TZ=CST6CDT git cvsimport -p-x -C module-1 module 
git cvsimport -p-x -C module-1 module 
(
cd module-1 
git log --format=%s %ai
) actual-1 
cat expect-1 -EOF 
Rev 16 2006-10-29 07:00:01 +
Rev 15 2006-10-29 06:59:59 +
Rev 14 2006-04-02 08:00:01 +
Rev 13 2006-04-02 07:59:59 +
Rev 12 2005-12-01 00:00:00 +
Rev 11 2005-11-01 00:00:00 +
Rev 10 2005-10-01 00:00:00 +
Rev  9 2005-09-01 00:00:00 +
Rev  8 2005-08-01 00:00:00 +
Rev  7 2005-07-01 00:00:00 +
Rev  6 2005-06-01 00:00:00 +
Rev  5 2005-05-01 00:00:00 +
Rev  4 2005-04-01 00:00:00 +
Rev  3 2005-03-01 00:00:00 +
Rev  2 2005-02-01 00:00:00 +
Rev  1 2005-01-01 00:00:00 +
EOF
test_cmp actual-1 expect-1

Initialized empty Git repository in /home/ramsay/git/t/trash 
directory.t9604-cvsimport-timestamps/module-1/.git/
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
* UNKNOWN LINE * Branches: 
Already up-to-date.
--- actual-12012-10-31 21:20:20.0 +
+++ expect-12012-10-31 21:20:20.0 +
@@ -13,4 +13,4 @@
 Rev  4 2005-04-01 00:00:00 +
 Rev  3 2005-03-01 00:00:00 +
 Rev  2 2005-02-01 00:00:00 +
-Rev  1 2004-12-31 18:00:00 +
+Rev  1 2005-01-01 00:00:00 +
not ok 1 - check timestamps are UTC (TZ=CST6CDT)
#
#
#   TZ=CST6CDT git cvsimport -p-x -C module-1 module 
#   git cvsimport -p-x -C module-1 module 
#   (
#   cd module-1 
#   git log --format=%s %ai
#   ) actual-1 
#   cat expect-1 -EOF 
#   Rev 16 2006-10-29 07:00:01 +
#   Rev 15 2006-10-29 06:59:59 +
#   Rev 14 2006-04-02 08:00:01 +
#   Rev 13 2006-04-02 07:59:59 +
#   Rev 12 2005-12-01 00:00:00 +
#   Rev 11 2005-11-01 00:00:00 +
#   Rev 10 2005-10-01 00:00:00 +
#   Rev  9 2005-09-01 00:00:00 +
#   Rev  8 2005-08-01 00:00:00 +
#   Rev  7 2005-07-01 00:00:00 +
#   Rev  6 2005-06-01 00:00:00 +
#   Rev  5 2005-05-01 00:00:00 +
#   Rev  4 2005-04-01 00:00:00 +
#   Rev  3 2005-03-01 00:00:00 +
#   Rev  2 2005-02-01 00:00:00 +
#   Rev  1 2005-01-01 00:00:00 +
#   EOF
#   test_cmp actual-1 expect-1
#

expecting success: 

cat cvs-authors -EOF 
user1=User One us...@domain.org
user2=User Two us...@domain.org CST6CDT
user3=User Three us...@domain.org EST5EDT
user4=User Four us...@domain.org

Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)

2012-11-01 Thread Chris Rorvick 
On Thu, Nov 1, 2012 at 1:40 PM, Ramsay Jones ram...@ramsay1.demon.co.uk wrote:
 Jeff King wrote:
 What's cooking in git.git (Oct 2012, #09; Mon, 29)
 --


 [snip]

 * cr/cvsimport-local-zone (2012-10-16) 1 commit
  - git-cvsimport: allow author-specific timezones

  Allows cvsimport to read per-author timezone from the author info
  file.

  Will merge to 'next'.

 Just FYI, t9604-cvsimport-timestamps.sh is still failing for me.

 I haven't spent too long on this yet, but I had hoped that setting
 TZ would sidestep any DST issues. (I have downloaded new tzdata, but
 have yet to install - actually I don't really want to!). It is not
 clear from the tzset manpage what happens if you use the DST format
 for TZ, but you don't provide the start/end date for DST, which is
 what this test is doing.

 Perhaps the test should use the non-DST format? e.g. TZ=CST6 git ...
 Does the test really care about DST? (*if* that is indeed the problem).

It actually looks like your TZ database is fine and the problem is
with the conversion to a struct tm.  In each case, the time is
localized to the previous TZ value while the offset for the current TZ
value.  For example, look at the first commit in the first test.  It
converted the timestamp to 18:00 (CST6) while all the rest came
through as expected.I suspect the previous version of cvsimport
would exhibit similar behavior with the first imported commit.  What
is your platform?

 Also: Note that the first test calls git-cvsimport twice, first *with*
 TZ set then again without; I suspect a cut/paste editing error.

Oops.  The second invocation should have no effect on the repo so the
unit test is still valid, but that was a mistake for sure.  Thanks.

Chris
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

What's cooking in git.git (Oct 2012, #09; Mon, 29)

2012-10-29 Thread Jeff King 
What's cooking in git.git (Oct 2012, #09; Mon, 29)
--

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

The second batch of topics has graduated to master. Most of the new
topics have been minor bugfixes or documentation updates, so I've merged
a lot of those to master.

You can find the changes described here in the integration branches of
my repository at:

  git://github.com/peff/git.git

Until Junio returns, kernel.org and the other usual places will not be
updated.

--
[New Topics]

* fc/completion-test-simplification (2012-10-29) 2 commits
 - completion: simplify __gitcomp test helper
 - completion: refactor __gitcomp related tests

 Clean up completion tests.

 Will merge to 'next'.


* fc/remote-testgit-feature-done (2012-10-29) 1 commit
 - remote-testgit: properly check for errors


* jk/maint-diff-grep-textconv (2012-10-28) 1 commit
 - diff_grep: use textconv buffers for add/deleted files
 (this branch is used by jk/pickaxe-textconv.)

 Fixes inconsistent use of textconv with git log -G.

 Will merge to 'next'.


* jk/pickaxe-textconv (2012-10-28) 2 commits
 - pickaxe: use textconv for -S counting
 - pickaxe: hoist empty needle check
 (this branch uses jk/maint-diff-grep-textconv.)

 Use textconv filters when searching with log -S.

 Waiting for a sanity check and review from Junio.


* km/maint-doc-git-reset (2012-10-29) 1 commit
  (merged to 'next' on 2012-10-29 at cdb4e8f)
 + doc: git-reset: make mode optional

 Will merge to 'master' in the third batch.


* mh/maint-parse-dirstat-fix (2012-10-29) 1 commit
 - parse_dirstat_params(): use string_list to split comma-separated string

 Cleans up some code and avoids a potential bug.

 Will merge to 'next'.


* nd/builtin-to-libgit (2012-10-29) 7 commits
 - fetch-pack: move core code to libgit.a
 - fetch-pack: remove global (static) configuration variable args
 - send-pack: move core code to libgit.a
 - Move setup_diff_pager to libgit.a
 - Move print_commit_list to libgit.a
 - Move estimate_bisect_steps to libgit.a
 - Move try_merge_command and checkout_fast_forward to libgit.a

 Code cleanups so that libgit.a does not depend on anything in the
 builtin/ directory.

 Some of the code movement is pretty big, but there doesn't seem to be
 any conflicts with topics in flight.

 Will merge to 'next'.


* ph/maint-submodule-status-fix (2012-10-29) 2 commits
 - submodule status: remove unused orig_* variables
 - t7407: Fix recursive submodule test

 Cleans up some leftover bits from an earlier submodule change.

 Will merge to 'next'.


* pp/maint-doc-pager-config (2012-10-29) 1 commit
  (merged to 'next' on 2012-10-29 at 434fbd0)
 + Documentation: improve the example of overriding LESS via core.pager

 Will merge to 'master' in the third batch.


* rf/maint-mailmap-off-by-one (2012-10-28) 1 commit
  (merged to 'next' on 2012-10-29 at 8c2214b)
 + mailmap: avoid out-of-bounds memory access

 Will merge to 'master' in the third batch.


* sz/maint-submodule-reference-arg (2012-10-26) 1 commit
  (merged to 'next' on 2012-10-29 at 1aab03c)
 + submodule add: fix handling of --reference=repo option

 Will merge to 'master' in the third batch.


* tb/maint-t9200-case-insensitive (2012-10-28) 1 commit
  (merged to 'next' on 2012-10-29 at 62af90c)
 + Fix t9200 on case insensitive file systems

 Will merge to 'master' in the third batch.


* tj/maint-doc-commit-sign (2012-10-29) 1 commit
  (merged to 'next' on 2012-10-29 at 44c61a0)
 + Add -S, --gpg-sign option to manpage of git commit

 Will merge to 'master' in the third batch.


--
[Graduated to master]

* jc/grep-pcre-loose-ends (2012-10-09) 7 commits
  (merged to 'next' on 2012-10-25 at 2ea9b27)
 + log: honor grep.* configuration
 + log --grep: accept --basic-regexp and --perl-regexp
 + log --grep: use the same helper to set -E/-F options as git grep
 + revisions: initialize revs-grep_filter using grep_init()
 + grep: move pattern-type bits support to top-level grep.[ch]
 + grep: move the configuration parsing logic to grep.[ch]
 + builtin/grep.c: make configuration callback more reusable

 git log -F -E --grep='ere' failed to use the given ere
 pattern as extended regular expression, and instead looked for the
 string literally.  The early part of this series is a fix for it.

 Will merge to 'master' in the second batch after 1.8.0 ships.


* jk/maint-http-init-not-in-result-handler (2012-10-12) 2 commits
  (merged to 'next' on 2012-10-25 at 59d3687)
 + http: do not set up curl auth after a 401
 + remote-curl: do not call run_slot repeatedly

 Further clean-up to the http codepath that picks up results after
 cURL library is done with one request slot.

 Will merge to 'master' in the second batch after 1.8.0 ships.


* jk/sh-setup-in-filter-branch (2012-10-18) 2