Git development
 help / color / mirror / Atom feed
* Re: inotify to minimize stat() calls
From: Ramkumar Ramachandra @ 2013-02-09 17:10 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Robert Zeh, Junio C Hamano, Git List, finnag
In-Reply-To: <CACsJy8CEHzqH1X=v4yau0SyZwrZp1r6hNp=yXD+eZh1q_BS-0g@mail.gmail.com>

Duy Nguyen wrote:
> How about this as a start? I did not really check what it does, but it
> does not look complicate enough to pull systemd in.
>
> http://article.gmane.org/gmane.comp.version-control.git/151934

Clever hack.  I didn't know that there was a switch called
core.ignoreStat which will disable automatic lstat() calls altogether.
 So, Finn advises that we set this switch and run igit instead of git.
 There's a git-inotify-daemon which runs inotifywait with -m forever,
updating a modified_files hash.  When it is sent a TERM from igit
(which is what happens immediately upon execution), it writes all this
collected information about modified files to a named pipe that igit
passes to it.  igit then does a git update-index --assume-unchained
--stdin to read the data from the pipe.  Towards the end of its life,
igit starts up a fresh git-inotify-daemon for future invocations.

Finn notes in the commit message that it offers no speedup, because
.gitignore files in every directory still have to be read.  I think
this is silly: we really should be caching .gitignore, and touching it
only when lstat() reports that the file has changed.

As far as a real implementation that we'd want to merge into git.git
is concerned, I have a few comments:
Running multiple daemons on-the-fly for monitoring filesystem changes
is not elegant at all.  Keeping track of the state of so many loose
daemons is a hard problem: how do we ensure any semblance of
reliability without that?  Systemd is a very big improvement over the
legacy of a hundred loose shell scripts that SysVInit demanded.  It
monitors and babysits daemons; it uses cgroups to even kill
misbehaving daemons.  I can inspect running daemons at any time, and
have a uniform way to start/ stop/ restart them.

Okay, now you're asking me to consider a system-wide daemon
independent of systemd.  It has to run with root privileges so it has
access to everyone's repositories, which means that people have to
trust it beyond doubt.  What does it do?  It has a generic API to
watch filesystem paths and report events over an IP socket.  Do you
think that this will only be useful to git?  Every other version
control system (and presumably many other pieces of software) will
want to use it.  One huge downside I see of making this part of
systemd is Ubuntu.  They've decided not to use systemd for some
unfathomable reason.

Really, the elephant in the room right now seems to be .gitignore.
Until that is fixed, there is really no use of writing this inotify
daemon, no?  Can someone enlighten me on how exactly .gitignore files
are processed?

> Youo may want to search the mail archive. This topic has come up a few
> times before, there may be other similar patches.

The thread you linked me to is a 2010 email, and now it's 2013.  We've
been silent about inotify for three years?

Thanks for your inputs, Duy.

^ permalink raw reply

* git-completion.bash --local
From: Dasa Paddock @ 2013-02-09 18:37 UTC (permalink / raw)
  To: git@vger.kernel.org

I think this line should include --local:

https://github.com/git/git/blob/next/contrib/completion/git-completion.bash#L1782
    "--global|--system|--file=*)"

This would help for:
    git config -l --local

Thanks,
Dasa Paddock

^ permalink raw reply

* Re: inotify to minimize stat() calls
From: Ramkumar Ramachandra @ 2013-02-09 18:56 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Robert Zeh, Junio C Hamano, Git List, Finn Arne Gangstad
In-Reply-To: <CALkWK0=6_n4rf6AWci6J+uhGHpjTUmK7YFdVHuSJedN2zLWtMA@mail.gmail.com>

Ramkumar Ramachandra wrote:
> Okay, now you're asking me to consider a system-wide daemon
> independent of systemd.  It has to run with root privileges so it has
> access to everyone's repositories, which means that people have to
> trust it beyond doubt.  What does it do?  It has a generic API to
> watch filesystem paths and report events over an IP socket.  Do you
> think that this will only be useful to git?  Every other version
> control system (and presumably many other pieces of software) will
> want to use it.  One huge downside I see of making this part of
> systemd is Ubuntu.  They've decided not to use systemd for some
> unfathomable reason.

After some thought, I've decided that extending systemd is not the way
to go.  And the dbus API is really an overkill.  Writing a simple
system-wide daemon shouldn't be a challenge; the hard part is getting
git to use it properly.

^ permalink raw reply

* Re: inotify to minimize stat() calls
From: Junio C Hamano @ 2013-02-09 19:35 UTC (permalink / raw)
  To: Ramkumar Ramachandra; +Cc: Robert Zeh, Git List, Duy Nguyen
In-Reply-To: <CALkWK0mttn6E+D-22UBbvDCuNEy_jNOtBaKPS-a8mTbO2uAF3g@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> This is much better than Junio's suggestion to study possible
> implementations on all platforms and designing a generic daemon/
> communication channel.  That's no weekend project.

It appears that you misunderstood what I wrote.  That was not "here
is a design; I want it in my system.  Go implemment it".

It was "If somebody wants to discuss it but does not know where to
begin, doing a small experiment like this and reporting how well it
worked here may be one way to do so.", nothing more.

^ permalink raw reply

* [PATCH] git-bisect.txt: clarify that reset finishes bisect
From: Michael J Gruber @ 2013-02-09 19:47 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Andreas Mohr

"reset" can be easily misunderstood as resetting a bisect session to its
start without finishing it. Clarify that it actually finishes the bisect
session.

Reported-by: Andreas Mohr <andi@lisas.de>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/git-bisect.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index b4831bb..d50bd89 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -83,7 +83,7 @@ Bisect reset
 ~~~~~~~~~~~~
 
 After a bisect session, to clean up the bisection state and return to
-the original HEAD, issue the following command:
+the original HEAD (i.e., to finish bisect), issue the following command:
 
 ------------------------------------------------
 $ git bisect reset
-- 
1.8.1.2.752.g32d147e

^ permalink raw reply related

* Re: [RFC/PATCH] Introduce branch.<name>.pushremote
From: Junio C Hamano @ 2013-02-09 20:00 UTC (permalink / raw)
  To: Ramkumar Ramachandra; +Cc: Git List, Jonathan Nieder, Jeff King
In-Reply-To: <CALkWK0kp5SvbeTQgLRKWUAT_koSi0wyp6iPTC324iH8+D8oeJg@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Junio C Hamano wrote:
>
>> In other words, does it make sense to read branch.$name.pushremote
>> for all the other irrelevant branches?
>>
>> In yet other words, perhaps adding pushremote_name to the branch
>> structure is unneeded, and you only need this single global
>> variable?
>
> Frankly, I'm unhappy with this global.  Setting a global here and
> subsequently reading it in pushremote_get() feels flaky.

Why unhappy?

This is expressed as a per-branch configuration, but in realitiy the
configuration on any branch that is not the current one does *not*
matter an iota.

An API call find_pushremote_for_branch() that takes a branch name
and returns the pushremote for that arbitrary branch has no use in
your designed feature.  find_pushremote() that tells you where a
lazy "git push" goes under the conditoin is the only thing you need
in your design.  You can still implement it without globals, e.g.

	struct bp { const char *branch; const char *remotename; };

        static int pushremote(const char *var, const char *val, void *cb)
	{
		struct bp *bp = cb;
	        const char *name, *key;
                int namelen;

		if (!parse_config_key(var, "branch", &name, &namelen, &key) &&
                    namelen == strlen(bp->branch) &&
                    !memcmp(name, bp->branch, name, namelen) &&
		    !strcmp(key, "remotepush")) {
			git_config_string(&bp->remotename, var, val);
		}
		return 0;
	}

	char *find_pushremote(void) {
		struct bp bp;

                bp.branch = get_current_branch();
                bp.remotename = NULL;
                git_config(pushremote, &bp);
                return bp.remotename;
	}


And if you want to take default.pushremote that changes a lazy "git
push" to go to somewhere other than "origin", you make the
pushremote() callback notice that variable, add one element
"defaultremote" to struct "bp" to record that value, and then make
find_pushremote() do

	return bp.remotename ? bp.remotename : bp.defaultremote;

Sometimes "global variable" feels disturbing because then we cannot
run more than one user at the same time.  One caller may want to
know the value for "foo" branch while another want it for "bar"
branch.

But there is no reason for anybody to want to know the value for the
variables branch.$name.pushremote for all defined $name's at the
same time, exactly because this matters only for the current branch,
no?
			

^ permalink raw reply

* Re: Please pull l10n updates for 1.8.2 round 1
From: Junio C Hamano @ 2013-02-09 21:44 UTC (permalink / raw)
  To: Jiang Xin
  Cc: Ralf Thielow, Thomas Rast, Wang Sheng, Peter Krefting,
	Tran Ngoc Quan, Git List
In-Reply-To: <CANYiYbHhGDFD3LZKGeRxkBF5s0TRHMvRBZY7c9T8zONiZGiNdA@mail.gmail.com>

Thanks.

^ permalink raw reply

* [PATCH 3/3] Avoid non-portable strftime format specifiers in git-cvsimport
From: Ben Walton @ 2013-02-09 21:46 UTC (permalink / raw)
  To: gitster; +Cc: git, Ben Walton
In-Reply-To: <1360446418-12280-1-git-send-email-bdwalton@gmail.com>

Neither %s or %z are portable strftime format specifiers.  There is no
need for %s in git-cvsimport as the supplied time is already in
seconds since the epoch.  For %z, use the function get_tz_offset
provided by Git.pm instead.

Signed-off-by: Ben Walton <bdwalton@gmail.com>
---
 git-cvsimport.perl |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 0a31ebd..344f120 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -26,6 +26,7 @@ use IO::Socket;
 use IO::Pipe;
 use POSIX qw(strftime tzset dup2 ENOENT);
 use IPC::Open2;
+use Git qw(get_tz_offset);
 
 $SIG{'PIPE'}="IGNORE";
 set_timezone('UTC');
@@ -864,7 +865,9 @@ sub commit {
 	}
 
 	set_timezone($author_tz);
-	my $commit_date = strftime("%s %z", localtime($date));
+	# $date is in the seconds since epoch format
+	my $tz_offset = get_tz_offset($date);
+	my $commit_date = "$date $tz_offset";
 	set_timezone('UTC');
 	$ENV{GIT_AUTHOR_NAME} = $author_name;
 	$ENV{GIT_AUTHOR_EMAIL} = $author_email;
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 1/3] Move Git::SVN::get_tz to Git::get_tz_offset
From: Ben Walton @ 2013-02-09 21:46 UTC (permalink / raw)
  To: gitster; +Cc: git, Ben Walton
In-Reply-To: <1360446418-12280-1-git-send-email-bdwalton@gmail.com>

This function has utility outside of the SVN module for any routine
that needs the equivalent of GNU strftime's %z formatting option.
Move it to the top-level Git.pm so that non-SVN modules don't need to
import the SVN module to use it.

The rename makes the purpose of the function clearer.

Signed-off-by: Ben Walton <bdwalton@gmail.com>
---
 perl/Git.pm         |   23 +++++++++++++++++++++++
 perl/Git/SVN.pm     |   12 ++----------
 perl/Git/SVN/Log.pm |    8 ++++++--
 3 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/perl/Git.pm b/perl/Git.pm
index 931047c..5649bcc 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -59,6 +59,7 @@ require Exporter;
                 command_bidi_pipe command_close_bidi_pipe
                 version exec_path html_path hash_object git_cmd_try
                 remote_refs prompt
+                get_tz_offset
                 temp_acquire temp_release temp_reset temp_path);
 
 
@@ -102,6 +103,7 @@ use Error qw(:try);
 use Cwd qw(abs_path cwd);
 use IPC::Open2 qw(open2);
 use Fcntl qw(SEEK_SET SEEK_CUR);
+use Time::Local qw(timelocal);
 }
 
 
@@ -511,6 +513,27 @@ C<git --html-path>). Useful mostly only internally.
 
 sub html_path { command_oneline('--html-path') }
 
+
+=item get_tz_offset ( TIME )
+
+Return the time zone offset from GMT in the form +/-HHMM where HH is
+the number of hours from GMT and MM is the number of minutes.  This is
+the equivalent of what strftime("%z", ...) would provide on a GNU
+platform.
+
+If TIME is not supplied, the current local time is used.
+
+=cut
+
+sub get_tz_offset {
+	# some systmes don't handle or mishandle %z, so be creative.
+	my $t = shift || time;
+	my $gm = timelocal(gmtime($t));
+	my $sign = qw( + + - )[ $t <=> $gm ];
+	return sprintf("%s%02d%02d", $sign, (gmtime(abs($t - $gm)))[2,1]);
+}
+
+
 =item prompt ( PROMPT , ISPASSWORD  )
 
 Query user C<PROMPT> and return answer from user.
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 490e330..0ebc68a 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -11,7 +11,6 @@ use Carp qw/croak/;
 use File::Path qw/mkpath/;
 use File::Copy qw/copy/;
 use IPC::Open3;
-use Time::Local;
 use Memoize;  # core since 5.8.0, Jul 2002
 use Memoize::Storable;
 use POSIX qw(:signal_h);
@@ -22,6 +21,7 @@ use Git qw(
     command_noisy
     command_output_pipe
     command_close_pipe
+    get_tz_offset
 );
 use Git::SVN::Utils qw(
 	fatal
@@ -1311,14 +1311,6 @@ sub get_untracked {
 	\@out;
 }
 
-sub get_tz {
-	# some systmes don't handle or mishandle %z, so be creative.
-	my $t = shift || time;
-	my $gm = timelocal(gmtime($t));
-	my $sign = qw( + + - )[ $t <=> $gm ];
-	return sprintf("%s%02d%02d", $sign, (gmtime(abs($t - $gm)))[2,1]);
-}
-
 # parse_svn_date(DATE)
 # --------------------
 # Given a date (in UTC) from Subversion, return a string in the format
@@ -1351,7 +1343,7 @@ sub parse_svn_date {
 			delete $ENV{TZ};
 		}
 
-		my $our_TZ = get_tz();
+		my $our_TZ = get_tz_offset();
 
 		# This converts $epoch_in_UTC into our local timezone.
 		my ($sec, $min, $hour, $mday, $mon, $year,
diff --git a/perl/Git/SVN/Log.pm b/perl/Git/SVN/Log.pm
index 3cc1c6f..3f8350a 100644
--- a/perl/Git/SVN/Log.pm
+++ b/perl/Git/SVN/Log.pm
@@ -2,7 +2,11 @@ package Git::SVN::Log;
 use strict;
 use warnings;
 use Git::SVN::Utils qw(fatal);
-use Git qw(command command_oneline command_output_pipe command_close_pipe);
+use Git qw(command
+           command_oneline
+           command_output_pipe
+           command_close_pipe
+           get_tz_offset);
 use POSIX qw/strftime/;
 use constant commit_log_separator => ('-' x 72) . "\n";
 use vars qw/$TZ $limit $color $pager $non_recursive $verbose $oneline
@@ -119,7 +123,7 @@ sub run_pager {
 sub format_svn_date {
 	my $t = shift || time;
 	require Git::SVN;
-	my $gmoff = Git::SVN::get_tz($t);
+	my $gmoff = get_tz_offset($t);
 	return strftime("%Y-%m-%d %H:%M:%S $gmoff (%a, %d %b %Y)", localtime($t));
 }
 
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 2/3] Fix get_tz_offset to properly handle DST boundary cases
From: Ben Walton @ 2013-02-09 21:46 UTC (permalink / raw)
  To: gitster; +Cc: git, Ben Walton
In-Reply-To: <1360446418-12280-1-git-send-email-bdwalton@gmail.com>

When passed a local time that was on the boundary of a DST change,
get_tz_offset returned a GMT offset that was incorrect (off by one
hour).  This is because the time was converted to GMT and then back to
a time stamp via timelocal() which cannot disambiguate boundary cases
as noted in its documentation.

Modify this algorithm, using an approach suggested by Junio C Hamano
that obtains the GMT time stamp by using timegm(localtime()) instead
of timelocal(gmtime()).  This avoids the ambigious conversion and
allows a correct time to be returned on every occassion.

Signed-off-by: Ben Walton <bdwalton@gmail.com>
---
 perl/Git.pm |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/perl/Git.pm b/perl/Git.pm
index 5649bcc..a56d1e7 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -103,7 +103,7 @@ use Error qw(:try);
 use Cwd qw(abs_path cwd);
 use IPC::Open2 qw(open2);
 use Fcntl qw(SEEK_SET SEEK_CUR);
-use Time::Local qw(timelocal);
+use Time::Local qw(timegm);
 }
 
 
@@ -528,8 +528,8 @@ If TIME is not supplied, the current local time is used.
 sub get_tz_offset {
 	# some systmes don't handle or mishandle %z, so be creative.
 	my $t = shift || time;
-	my $gm = timelocal(gmtime($t));
-	my $sign = qw( + + - )[ $t <=> $gm ];
+	my $gm = timegm(localtime($t));
+	my $sign = qw( + + - )[ $gm <=> $t ];
 	return sprintf("%s%02d%02d", $sign, (gmtime(abs($t - $gm)))[2,1]);
 }
 
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 0/3] Fix a portability issue with git-cvsimport
From: Ben Walton @ 2013-02-09 21:46 UTC (permalink / raw)
  To: gitster; +Cc: git, Ben Walton

This is my (long overdue) re-roll of the series that fixes a
portability issue with git-cvsimport's use of strftime.  It also fixes
a but in the original implementation of get_tz (now get_tz_offset).

I ended up taking taking only part of the implementation suggested by
Junio.

The only usage of get_tz_offset is by git-cvsimport and Git::SVN::Log
currently.  There are tests that validate it works currently so I
didn't add anything additional.  If the git-cvsimport tests are
removed, there are no tests remaining that exercise the code full as
the SVN tests use UTC times.

Ben Walton (3):
  Move Git::SVN::get_tz to Git::get_tz_offset
  Fix get_tz_offset to properly handle DST boundary cases
  Avoid non-portable strftime format specifiers in git-cvsimport

 git-cvsimport.perl  |    5 ++++-
 perl/Git.pm         |   23 +++++++++++++++++++++++
 perl/Git/SVN.pm     |   12 ++----------
 perl/Git/SVN/Log.pm |    8 ++++++--
 4 files changed, 35 insertions(+), 13 deletions(-)

-- 
1.7.10.4

^ permalink raw reply

* Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect
From: Junio C Hamano @ 2013-02-09 21:53 UTC (permalink / raw)
  To: Michael J Gruber; +Cc: git, Andreas Mohr
In-Reply-To: <5e23d4c420f150b700dd5100bffb38d32f874200.1360439176.git.git@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

> "reset" can be easily misunderstood as resetting a bisect session to its
> start without finishing it. Clarify that it actually finishes the bisect
> session.
>
> Reported-by: Andreas Mohr <andi@lisas.de>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
>  Documentation/git-bisect.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index b4831bb..d50bd89 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -83,7 +83,7 @@ Bisect reset
>  ~~~~~~~~~~~~
>  
>  After a bisect session, to clean up the bisection state and return to
> -the original HEAD, issue the following command:
> +the original HEAD (i.e., to finish bisect), issue the following command:

Makes sense.

^ permalink raw reply

* Re: [PATCH 3/3] Avoid non-portable strftime format specifiers in git-cvsimport
From: Junio C Hamano @ 2013-02-09 22:20 UTC (permalink / raw)
  To: Ben Walton; +Cc: git
In-Reply-To: <1360446418-12280-4-git-send-email-bdwalton@gmail.com>

Ben Walton <bdwalton@gmail.com> writes:

> Neither %s or %z are portable strftime format specifiers.

Well, at least %z is in POSIX; "Some implementations of strftime(3)
lack support for %z format" is fine, tough.

Thanks.

^ permalink raw reply

* Re: [PATCH 2/3] Fix get_tz_offset to properly handle DST boundary cases
From: Junio C Hamano @ 2013-02-09 22:58 UTC (permalink / raw)
  To: Ben Walton; +Cc: git
In-Reply-To: <1360446418-12280-3-git-send-email-bdwalton@gmail.com>

Ben Walton <bdwalton@gmail.com> writes:

> When passed a local time that was on the boundary of a DST change,
> get_tz_offset returned a GMT offset that was incorrect (off by one
> hour).  This is because the time was converted to GMT and then back to
> a time stamp via timelocal() which cannot disambiguate boundary cases
> as noted in its documentation.
>
> Modify this algorithm, using an approach suggested by Junio C Hamano
> that obtains the GMT time stamp by using timegm(localtime()) instead
> of timelocal(gmtime()).  This avoids the ambigious conversion and
> allows a correct time to be returned on every occassion.

I'll reword the log message a bit to explain why the updated logic
is right and also refer to the message that has the suggestion.  o

The implemmentation is a bit dense to my taste, but looks correct (I
had to think about the comparison to come up with the value of the
$sign, though).

Thanks.

> Signed-off-by: Ben Walton <bdwalton@gmail.com>
> ---
>  perl/Git.pm |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/perl/Git.pm b/perl/Git.pm
> index 5649bcc..a56d1e7 100644
> --- a/perl/Git.pm
> +++ b/perl/Git.pm
> @@ -103,7 +103,7 @@ use Error qw(:try);
>  use Cwd qw(abs_path cwd);
>  use IPC::Open2 qw(open2);
>  use Fcntl qw(SEEK_SET SEEK_CUR);
> -use Time::Local qw(timelocal);
> +use Time::Local qw(timegm);
>  }
>  
>  
> @@ -528,8 +528,8 @@ If TIME is not supplied, the current local time is used.
>  sub get_tz_offset {
>  	# some systmes don't handle or mishandle %z, so be creative.
>  	my $t = shift || time;
> -	my $gm = timelocal(gmtime($t));
> -	my $sign = qw( + + - )[ $t <=> $gm ];
> +	my $gm = timegm(localtime($t));
> +	my $sign = qw( + + - )[ $gm <=> $t ];
>  	return sprintf("%s%02d%02d", $sign, (gmtime(abs($t - $gm)))[2,1]);
>  }

^ permalink raw reply

* Re: Feature request: Allow extracting revisions into directories
From: Junio C Hamano @ 2013-02-09 23:00 UTC (permalink / raw)
  To: Robert Clausecker; +Cc: git, Phil Hord
In-Reply-To: <1360425499.3369.10.camel@t520>

Robert Clausecker <fuzxxl@gmail.com> writes:

> After thinking a while about how to solve the problems I have, I
> consider the following things as a solution to my problem.
>
> Add an option --isolated, -i to git checkout: Check out a branch / tag /
> revision but do not touch the index. This could be used together with
> --work-tree to check out a branch into an arbitrary directory. Also, it
> satisfies all 4 criteria from [1] and therefore is perfect for
> deployment from a bare repository.
>
> What do you think about this feature request?

I am not Phil, but if you ask me, I think it is borderline between
"meh" and "no way we would give a short-and-sweet -i to something
like this".

^ permalink raw reply

* Re: [PATCH v2 06/10] sequencer.c: teach append_signoff how to detect duplicate s-o-b
From: Junio C Hamano @ 2013-02-09 23:06 UTC (permalink / raw)
  To: Brandon Casey; +Cc: Jonathan Nieder, pclouds, git, Brandon Casey
In-Reply-To: <7v7gmy12op.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

> Brandon Casey <drafnel@gmail.com> writes:
>
>> On Tue, Jan 22, 2013 at 12:38 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>> Brandon Casey wrote:
>>>
>>>> Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
>>>> This is in preparation to unify the append_signoff implementations in
>>>> log-tree.c and sequencer.c.
>>> [...]
>>>> --- a/sequencer.c
>>>> +++ b/sequencer.c
>>>> @@ -1082,9 +1101,10 @@ int sequencer_pick_revisions(struct replay_opts *opts)
>>>>       return pick_commits(todo_list, opts);
>>>>  }
>>>>
>>>> -void append_signoff(struct strbuf *msgbuf, int ignore_footer)
>>>> +void append_signoff(struct strbuf *msgbuf, int ignore_footer, int no_dup_sob)
>>>
>>> Isn't the behavior of passing '1' here just a bug in "format-patch -s"?
>>
>> I think that is an open question.
>
> Yes. as I said in a previous review round, I think it was a mistake
> that format-patch chose to pay attention to any S-o-b in the patch
> trail, not only the last one, and we may want to correcct it once
> this series solidifies as a separate "bugfix" change on top.

This is a tangent, but I _think_ (didn't check, though) "git am -s"
implements this incorrrectly.  Just another LHF somebody may want to
take a look.

^ permalink raw reply

* Re: [PATCH v3 0/8] Hiding refs
From: Junio C Hamano @ 2013-02-09 23:23 UTC (permalink / raw)
  To: Jed Brown; +Cc: Michael Haggerty, git, Jeff King, Shawn Pearce
In-Reply-To: <87pq0c15h3.fsf@59A2.org>

Jed Brown <jed@59A2.org> writes:

> I believe that my use case would be well supported if git could push and
> pull unadvertised refs, as long as basic operations were not slowed down
> by the existence of a very large number of such refs.

I am not sure about "pushing" part, but the jc/fetch-raw-sha1 topic
(split from the main jc/hidden-refs topic) should allow your script,
after the client learns the set of smudged object names, to ask for

    git fetch $there $sha1_1 $sha1_2 ...

or

    git fetch $there $sha1_1:refs/fat/$sha1_1 $sha1_2:refs/fat/$sha1_2 ...

I think.

^ permalink raw reply

* Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect
From: Andreas Mohr @ 2013-02-09 23:24 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Michael J Gruber, git, Andreas Mohr
In-Reply-To: <7v8v6xw3wf.fsf@alter.siamese.dyndns.org>

Hi,

On Sat, Feb 09, 2013 at 01:53:04PM -0800, Junio C Hamano wrote:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> >  After a bisect session, to clean up the bisection state and return to
> > -the original HEAD, issue the following command:
> > +the original HEAD (i.e., to finish bisect), issue the following command:
> 
> Makes sense.

Doesn't ;)

[aww, very sorry for this blunt reply]

The main point of my mail was to stretch the (whether actually intended)
*perceived* start <-> stop symmetry
(which a *user* quite likely would end up searching for in the document,
and fail to find any "stop" keyword, thus not getting to the relevant
reset parameter section in time).
Quite likely I failed to properly word things to make that obvious,
in my quickly carved mail.


To clarify intent behind these docs, I would thus propose to have
the sentence improved to something quite similar to

the original HEAD (i.e., to finish - "stop" a started - bisect),
issue the following command:


Thanks a ton for your immediate handling of my wishlist item!

Andreas Mohr

^ permalink raw reply

* Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect
From: Junio C Hamano @ 2013-02-09 23:35 UTC (permalink / raw)
  To: Andreas Mohr; +Cc: Michael J Gruber, git
In-Reply-To: <20130209232455.GA31027@rhlx01.hs-esslingen.de>

Andreas Mohr <andi@lisas.de> writes:

> On Sat, Feb 09, 2013 at 01:53:04PM -0800, Junio C Hamano wrote:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>> >  After a bisect session, to clean up the bisection state and return to
>> > -the original HEAD, issue the following command:
>> > +the original HEAD (i.e., to finish bisect), issue the following command:
>> 
>> Makes sense.
>
> Doesn't ;)
>
> [aww, very sorry for this blunt reply]
>
> The main point of my mail was to stretch the (whether actually intended)
> *perceived* start <-> stop symmetry

Actually, in that sense, I do no think finish is exactly a good
wording.  The majority of use case would be to finish up after you
found the sole culprit, so in that sense "finish" is not too bad,
but in general, when you "reset", there is not necessarily any
symmmetry with "start".  We should definitely not be giving you an
illusion that there is one by using "stop" [*1*].

It is more like "abort".

I may be done with bisection after running the bisection to the very
end, of I may have realized that the problem is not bisectable due
to many reasons (e.g. the sympotom may be intermittent, or it has
already become apparent that there are more than one cause of the
observed breakage) way before we found "the first bad commit".

And "reset" cleans the bisectoin state and returns to the original
HEAD, regardless of the reason why you are cleaning up.  If we were
to add any explanation to the sentence, I think "finish" makes a lot
more sense than "stop".


[Footnote]

*1* another reason to avoid "stop" is that it could mean "I stop
here for now, to later come back and start digging again from
there", which is not "reset" is about at all.

^ permalink raw reply

* What's cooking in git.git (Feb 2013, #04; Sat, 9)
From: Junio C Hamano @ 2013-02-09 23:39 UTC (permalink / raw)
  To: git

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

As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 late next week.  I expect that topics that are not
mentioned in this message will not have enough time to be in the
upcomming release (unless they are obvious regression fixes or
documentation updates).

You can find the changes described here in the integration branches of the
repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[Graduated to "master"]

* ab/gitweb-use-same-scheme (2013-01-28) 1 commit
  (merged to 'next' on 2013-02-02 at 7e4a108)
 + gitweb: refer to picon/gravatar images over the same scheme

 Avoid mixed contents on a page coming via http and https when
 gitweb is hosted on a https server.


* ct/autoconf-htmldir (2013-02-02) 1 commit
  (merged to 'next' on 2013-02-05 at bba4f8c)
 + Honor configure's htmldir switch

 The autoconf subsystem passed --mandir down to generated
 config.mak.autogen but forgot to do the same for --htmldir.


* da/mergetool-docs (2013-02-02) 5 commits
  (merged to 'next' on 2013-02-03 at f822dcf)
 + doc: generate a list of valid merge tools
 + mergetool--lib: list user configured tools in '--tool-help'
 + mergetool--lib: add functions for finding available tools
 + mergetool--lib: improve the help text in guess_merge_tool()
 + mergetool--lib: simplify command expressions
 (this branch uses jk/mergetool.)

 Build on top of the clean-up done by jk/mergetool and automatically
 generate the list of mergetool and difftool backends the build
 supports to be included in the documentation.


* jc/combine-diff-many-parents (2013-02-05) 2 commits
  (merged to 'next' on 2013-02-05 at e382aa6)
 + t4038: add tests for "diff --cc --raw <trees>"
 + combine-diff: lift 32-way limit of combined diff

 We used to have an arbitrary 32 limit for combined diff input,
 resulting in incorrect number of leading colons shown when showing
 the "--raw --cc" output.


* jk/apply-similaritly-parsing (2013-02-03) 1 commit
  (merged to 'next' on 2013-02-05 at ccf1c97)
 + builtin/apply: tighten (dis)similarity index parsing

 Make sure the similarity value shown in the "apply --summary"
 output is sensible, even when the input had a bogus value.


* jk/doc-makefile-cleanup (2013-02-01) 1 commit
  (merged to 'next' on 2013-02-02 at 86ff373)
 + Documentation/Makefile: clean up MAN*_TXT lists


* jk/mergetool (2013-01-28) 8 commits
  (merged to 'next' on 2013-02-03 at 2ff5dee)
 + mergetools: simplify how we handle "vim" and "defaults"
 + mergetool--lib: don't call "exit" in setup_tool
 + mergetool--lib: improve show_tool_help() output
 + mergetools/vim: remove redundant diff command
 + git-difftool: use git-mergetool--lib for "--tool-help"
 + git-mergetool: don't hardcode 'mergetool' in show_tool_help
 + git-mergetool: remove redundant assignment
 + git-mergetool: move show_tool_help to mergetool--lib
 (this branch is used by da/mergetool-docs.)

 Cleans up mergetool/difftool combo.


* jk/python-styles (2013-01-30) 1 commit
  (merged to 'next' on 2013-02-02 at 293edc1)
 + CodingGuidelines: add Python coding guidelines


* jk/remote-helpers-doc (2013-02-01) 1 commit
  (merged to 'next' on 2013-02-02 at ce1461a)
 + Rename {git- => git}remote-helpers.txt

 "git help remote-helpers" did not work; 'remote-helpers' is not
 a subcommand name but a concept, so its documentation should have
 been in gitremote-helpers, not git-remote-helpers.


* mk/tcsh-complete-only-known-paths (2013-02-03) 1 commit
  (merged to 'next' on 2013-02-05 at 4409b08)
 + completion: handle path completion and colon for tcsh script
 (this branch uses mp/complete-paths.)

 Manlio's "complete with known paths only" update to completion
 scripts returns directory names without trailing slash to
 compensate the addition of '/' done by bash that reads from our
 completion result.  tcsh completion code that reads from our
 internal completion result does not add '/', so let it ask our
 complletion code to keep the '/' at the end.


* mp/complete-paths (2013-01-11) 1 commit
  (merged to 'next' on 2013-01-30 at 70e4f1a)
 + git-completion.bash: add support for path completion
 (this branch is used by mk/tcsh-complete-only-known-paths.)

 The completion script used to let the default completer to suggest
 pathnames, which gave too many irrelevant choices (e.g. "git add"
 would not want to add an unmodified path).  Teach it to use a more
 git-aware logic to enumerate only relevant ones.


* nd/branch-error-cases (2013-01-31) 6 commits
  (merged to 'next' on 2013-02-02 at cf5e745)
 + branch: let branch filters imply --list
 + docs: clarify git-branch --list behavior
 + branch: mark more strings for translation
 + Merge branch 'nd/edit-branch-desc-while-detached' into HEAD
 + branch: give a more helpful message on redundant arguments
 + branch: reject -D/-d without branch name

 Fix various error messages and conditions in "git branch", e.g. we
 advertised "branch -d/-D" to remove one or more branches but actually
 implemented removal of zero or more branches---request to remove no
 branches was not rejected.


* sb/gpg-i18n (2013-01-31) 1 commit
  (merged to 'next' on 2013-02-02 at 7a54574)
 + gpg: allow translation of more error messages


* sb/run-command-fd-error-reporting (2013-02-01) 1 commit
  (merged to 'next' on 2013-02-02 at be7e970)
 + run-command: be more informative about what failed


* ss/mergetools-tortoise (2013-02-01) 2 commits
  (merged to 'next' on 2013-02-03 at d306b83)
 + mergetools: teach tortoisemerge to handle filenames with SP correctly
 + mergetools: support TortoiseGitMerge

 Update mergetools to work better with newer merge helper tortoise ships.

--------------------------------------------------
[New Topics]

* jc/fetch-raw-sha1 (2013-02-07) 4 commits
 - fetch: fetch objects by their exact SHA-1 object names
 - upload-pack: optionally allow fetching from the tips of hidden refs
 - fetch: use struct ref to represent refs to be fetched
 - parse_fetch_refspec(): clarify the codeflow a bit
 (this branch uses jc/hidden-refs.)

 Allows requests to fetch objects at any tip of refs (including
 hidden ones).  It seems that there may be use cases even outside
 Gerrit (e.g. $gmane/215701).


* jk/diff-graph-cleanup (2013-02-07) 6 commits
 - combine-diff.c: teach combined diffs about line prefix
 - diff.c: use diff_line_prefix() where applicable
 - diff: add diff_line_prefix function
 - diff.c: make constant string arguments const
 - diff: write prefix to the correct file
 - graph: output padding for merge subsequent parents

 Refactors a lot of repetitive code sequence from the graph drawing
 code and adds it to the combined diff output.

 Will merge to 'next'.


* mn/send-email-works-with-credential (2013-02-07) 5 commits
 - git-send-email: use git credential to obtain password
 - Git.pm: add interface for git credential command
 - Git.pm: allow pipes to be closed prior to calling command_close_bidi_pipe
 - Git.pm: fix example in command_close_bidi_pipe documentation
 - Git.pm: allow command_close_bidi_pipe to be called as method

 Hooks the credential system to send-email.

 Expecting a reroll.
 $gmane/215752


* tz/perl-styles (2013-02-06) 1 commit
  (merged to 'next' on 2013-02-09 at c8cff17)
 + Update CodingGuidelines for Perl

 Add coding guidelines for writing Perl scripts for Git.

 Will merge to 'master'.


* al/mergetool-printf-fix (2013-02-08) 1 commit
 - git-mergetool: print filename when it contains %

 Will merge to 'next'.


* jk/error-const-return (2013-02-08) 1 commit
 - Use __VA_ARGS__ for all of error's arguments

 Will merge to 'next'.


* mm/allow-contrib-build (2013-02-07) 2 commits
 - perl.mak: introduce $(GIT_ROOT_DIR) to allow inclusion from other directories
 - Makefile: extract perl-related rules to make them available from other dirs

 Will merge to 'next'.


* mm/remote-mediawiki-build (2013-02-08) 2 commits
 - git-remote-mediawiki: use toplevel's Makefile
 - Makefile: make script-related rules usable from subdirectories

 Will merge to 'next'.


* nd/branch-show-rebase-bisect-state (2013-02-08) 1 commit
 - branch: show rebase/bisect info when possible instead of "(no branch)"

 Will merge to 'next'.


* nd/count-garbage (2013-02-08) 3 commits
 - count-objects: report how much disk space taken by garbage files
 - count-objects: report garbage files in pack directory too
 - git-count-objects.txt: describe each line in -v output

 Expecting a reroll.
 $gmane/215843


* wk/gc-auto-is-available-these-days (2013-02-08) 1 commit
 - user-manual: Rewrite git-gc section for automatic packing

 Will merge to 'next'.


* wk/man-deny-current-branch-is-default-these-days (2013-02-08) 1 commit
 - user-manual: Update for receive.denyCurrentBranch=refuse

 Will merge to 'next'.


* bw/get-tz-offset-perl (2013-02-09) 3 commits
 - cvsimport: format commit timestamp ourselves without using strftime
 - perl/Git.pm: fix get_tz_offset to properly handle DST boundary cases
 - Move Git::SVN::get_tz to Git::get_tz_offset

 Will merge to 'next'.


* mg/bisect-doc (2013-02-09) 1 commit
 - git-bisect.txt: clarify that reset finishes bisect

 Will merge to 'next'.

--------------------------------------------------
[Stalled]

* mp/diff-algo-config (2013-01-16) 3 commits
 - diff: Introduce --diff-algorithm command line option
 - config: Introduce diff.algorithm variable
 - git-completion.bash: Autocomplete --minimal and --histogram for git-diff

 Add diff.algorithm configuration so that the user does not type
 "diff --histogram".

 Looking better; may want tests to protect it from future breakages,
 but otherwise it looks ready for 'next'.

 Expecting a follow-up to add tests.


* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
 - Highlight the link target line in Gitweb using CSS

 Expecting a reroll.
 $gmane/211935


* jk/lua-hackery (2012-10-07) 6 commits
 - pretty: fix up one-off format_commit_message calls
 - Minimum compilation fixup
 - Makefile: make "lua" a bit more configurable
 - add a "lua" pretty format
 - add basic lua infrastructure
 - pretty: make some commit-parsing helpers more public

 Interesting exercise. When we do this for real, we probably would want
 to wrap a commit to make it more like an "object" with methods like
 "parents", etc.


* rc/maint-complete-git-p4 (2012-09-24) 1 commit
 - Teach git-completion about git p4

 Comment from Pete will need to be addressed ($gmane/206172).


* jc/maint-name-rev (2012-09-17) 7 commits
 - describe --contains: use "name-rev --algorithm=weight"
 - name-rev --algorithm=weight: tests and documentation
 - name-rev --algorithm=weight: cache the computed weight in notes
 - name-rev --algorithm=weight: trivial optimization
 - name-rev: --algorithm option
 - name_rev: clarify the logic to assign a new tip-name to a commit
 - name-rev: lose unnecessary typedef

 "git name-rev" names the given revision based on a ref that can be
 reached in the smallest number of steps from the rev, but that is
 not useful when the caller wants to know which tag is the oldest one
 that contains the rev.  This teaches a new mode to the command that
 uses the oldest ref among those which contain the rev.

 I am not sure if this is worth it; for one thing, even with the help
 from notes-cache, it seems to make the "describe --contains" even
 slower. Also the command will be unusably slow for a user who does
 not have a write access (hence unable to create or update the
 notes-cache).

 Stalled mostly due to lack of responses.


* jc/xprm-generation (2012-09-14) 1 commit
 - test-generation: compute generation numbers and clock skews

 A toy to analyze how bad the clock skews are in histories of real
 world projects.

 Stalled mostly due to lack of responses.


* jc/add-delete-default (2012-08-13) 1 commit
 - git add: notice removal of tracked paths by default

 "git add dir/" updated modified files and added new files, but does
 not notice removed files, which may be "Huh?" to some users.  They
 can of course use "git add -A dir/", but why should they?

 Resurrected from graveyard, as I thought it was a worthwhile thing
 to do in the longer term.

 Stalled mostly due to lack of responses.


* mb/remote-default-nn-origin (2012-07-11) 6 commits
 - Teach get_default_remote to respect remote.default.
 - Test that plain "git fetch" uses remote.default when on a detached HEAD.
 - Teach clone to set remote.default.
 - Teach "git remote" about remote.default.
 - Teach remote.c about the remote.default configuration setting.
 - Rename remote.c's default_remote_name static variables.

 When the user does not specify what remote to interact with, we
 often attempt to use 'origin'.  This can now be customized via a
 configuration variable.

 Expecting a reroll.
 $gmane/210151

 "The first remote becomes the default" bit is better done as a
 separate step.


* nd/parse-pathspec (2013-01-11) 20 commits
 . Convert more init_pathspec() to parse_pathspec()
 . Convert add_files_to_cache to take struct pathspec
 . Convert {read,fill}_directory to take struct pathspec
 . Convert refresh_index to take struct pathspec
 . Convert report_path_error to take struct pathspec
 . checkout: convert read_tree_some to take struct pathspec
 . Convert unmerge_cache to take struct pathspec
 . Convert read_cache_preload() to take struct pathspec
 . add: convert to use parse_pathspec
 . archive: convert to use parse_pathspec
 . ls-files: convert to use parse_pathspec
 . rm: convert to use parse_pathspec
 . checkout: convert to use parse_pathspec
 . rerere: convert to use parse_pathspec
 . status: convert to use parse_pathspec
 . commit: convert to use parse_pathspec
 . clean: convert to use parse_pathspec
 . Export parse_pathspec() and convert some get_pathspec() calls
 . Add parse_pathspec() that converts cmdline args to struct pathspec
 . pathspec: save the non-wildcard length part

 Uses the parsed pathspec structure in more places where we used to
 use the raw "array of strings" pathspec.

 Ejected from 'pu' for now; will take a look at the rerolled one
 later ($gmane/213340).

--------------------------------------------------
[Cooking]

* jc/extended-fake-ancestor-for-gitlink (2013-02-05) 1 commit
  (merged to 'next' on 2013-02-09 at 2d3547b)
 + apply: verify submodule commit object name better

 Instead of requiring the full 40-hex object names on the index
 line, we can read submodule commit object names from the textual
 diff when synthesizing a fake ancestore tree for "git am -3".

 Will merge to 'master'.


* tz/credential-authinfo (2013-02-05) 1 commit
 - Add contrib/credentials/netrc with GPG support

 A new read-only credential helper (in contrib/) to interact with
 the .netrc/.authinfo files.  Hopefully mn/send-email-authinfo topic
 can rebuild on top of something like this.

 Expecting a reroll.
 $gmane/215556


* jx/utf8-printf-width (2013-02-09) 1 commit
 - Add utf8_fprintf helper that returns correct number of columns

 Use a new helper that prints a message and counts its display width
 to align the help messages parse-options produces.

 Will merge to 'next'.


* dg/subtree-fixes (2013-02-05) 6 commits
  (merged to 'next' on 2013-02-09 at 8f19ebe)
 + contrib/subtree: make the manual directory if needed
 + contrib/subtree: honor DESTDIR
 + contrib/subtree: fix synopsis
 + contrib/subtree: better error handling for 'subtree add'
 + contrib/subtree: use %B for split subject/body
 + contrib/subtree: remove test number comments

 contrib/subtree updates, but here are only the ones that looked
 ready to be merged to 'next'.  For the remainder, they will have
 another day.

 Will merge to 'master'.


* jl/submodule-deinit (2013-02-06) 1 commit
 - submodule: add 'deinit' command

 There was no Porcelain way to say "I no longer am interested in
 this submodule", once you express your interest in a submodule with
 "submodule init".  "submodule deinit" is the way to do so.

 Will merge to 'next'.


* jc/remove-export-from-config-mak-in (2013-02-03) 1 commit
  (merged to 'next' on 2013-02-07 at 33f7d4f)
 + config.mak.in: remove unused definitions

 config.mak.in template had an "export" line to cause a few
 common makefile variables to be exported; if they need to be
 expoted for autoconf/configure users, they should also be exported
 for people who write config.mak the same way.  Move the "export" to
 the main Makefile.


* nd/status-show-in-progress (2013-02-05) 1 commit
 - status: show the branch name if possible in in-progress info

 Will merge to 'next'.


* sp/smart-http-content-type-check (2013-02-06) 3 commits
  (merged to 'next' on 2013-02-06 at 8bc6434)
 + http_request: reset "type" strbuf before adding
  (merged to 'next' on 2013-02-05 at 157812c)
 + t5551: fix expected error output
  (merged to 'next' on 2013-02-04 at d0759cb)
 + Verify Content-Type from smart HTTP servers

 The smart HTTP clients forgot to verify the content-type that comes
 back from the server side to make sure that the request is being
 handled properly.

 Will merge to 'master'.


* jc/mention-tracking-for-pull-default (2013-01-31) 1 commit
 - doc: mention tracking for pull.default

 We stopped mentioning `tracking` is a deprecated but supported
 synonym for `upstream` in pull.default even though we have no
 intention of removing the support for it.

 This is my "don't list it to catch readers' eyes, but make sure it
 can be found if the reader looks for it" version; I'm not married
 to the layout and will be happy to take a replacement patch.

 Waiting for couter-proposal patches.


* jc/hidden-refs (2013-02-07) 3 commits
 - upload/receive-pack: allow hiding ref hierarchies
 - upload-pack: simplify request validation
 - upload-pack: share more code
 (this branch is used by jc/fetch-raw-sha1.)

 Allow the server side to redact the refs/ namespace it shows to the
 client.

 I think this is ready for 'next'.


* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
  (merged to 'next' on 2013-01-30 at b639b47)
 + simplify-merges: drop merge from irrelevant side branch

 The --simplify-merges logic did not cull irrelevant parents from a
 merge that is otherwise not interesting with respect to the paths
 we are following.

 This touches a fairly core part of the revision traversal
 infrastructure; even though I think this change is correct, please
 report immediately if you find any unintended side effect.

 Will cook in 'next'.


* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
  (merged to 'next' on 2013-01-16 at 23f5df2)
 + t5570: do not assume the "matching" push is the default
 + t5551: do not assume the "matching" push is the default
 + t5550: do not assume the "matching" push is the default
  (merged to 'next' on 2013-01-09 at 74c3498)
 + doc: push.default is no longer "matching"
 + push: switch default from "matching" to "simple"
 + t9401: do not assume the "matching" push is the default
 + t9400: do not assume the "matching" push is the default
 + t7406: do not assume the "matching" push is the default
 + t5531: do not assume the "matching" push is the default
 + t5519: do not assume the "matching" push is the default
 + t5517: do not assume the "matching" push is the default
 + t5516: do not assume the "matching" push is the default
 + t5505: do not assume the "matching" push is the default
 + t5404: do not assume the "matching" push is the default

 Will cook in 'next' until Git 2.0 ;-).


* bc/append-signed-off-by (2013-01-27) 11 commits
 - Unify appending signoff in format-patch, commit and sequencer
 - format-patch: update append_signoff prototype
 - t4014: more tests about appending s-o-b lines
 - sequencer.c: teach append_signoff to avoid adding a duplicate newline
 - sequencer.c: teach append_signoff how to detect duplicate s-o-b
 - sequencer.c: always separate "(cherry picked from" from commit body
 - sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
 - t/t3511: add some tests of 'cherry-pick -s' functionality
 - t/test-lib-functions.sh: allow to specify the tag name to test_commit
 - commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
 - sequencer.c: rework search for start of footer to improve clarity

 Waiting for the final round of reroll before merging to 'next'.
 After that we will go incremental.

--------------------------------------------------
[Discarded]

* mn/send-email-authinfo (2013-01-29) 1 commit
 . git-send-email: add ~/.authinfo parsing

 Instead of making send-email directly read from .netrc/.authinfo,
 mn/send-email-works-with-credential topic hooks the program to our
 credential framework, and tz/credential-authinfo topic gives access
 to these file formats to credential consumers.

^ permalink raw reply

* Re: [PATCH v2 06/10] sequencer.c: teach append_signoff how to detect duplicate s-o-b
From: Brandon Casey @ 2013-02-09 23:49 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Brandon Casey, Jonathan Nieder, pclouds@gmail.com,
	git@vger.kernel.org
In-Reply-To: <7v7gmhulya.fsf@alter.siamese.dyndns.org>

On 2/9/2013 3:06 PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Brandon Casey <drafnel@gmail.com> writes:
>>
>>> On Tue, Jan 22, 2013 at 12:38 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>>> Brandon Casey wrote:
>>>>
>>>>> Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
>>>>> This is in preparation to unify the append_signoff implementations in
>>>>> log-tree.c and sequencer.c.
>>>> [...]
>>>>> --- a/sequencer.c
>>>>> +++ b/sequencer.c
>>>>> @@ -1082,9 +1101,10 @@ int sequencer_pick_revisions(struct replay_opts *opts)
>>>>>       return pick_commits(todo_list, opts);
>>>>>  }
>>>>>
>>>>> -void append_signoff(struct strbuf *msgbuf, int ignore_footer)
>>>>> +void append_signoff(struct strbuf *msgbuf, int ignore_footer, int no_dup_sob)
>>>>
>>>> Isn't the behavior of passing '1' here just a bug in "format-patch -s"?
>>>
>>> I think that is an open question.
>>
>> Yes. as I said in a previous review round, I think it was a mistake
>> that format-patch chose to pay attention to any S-o-b in the patch
>> trail, not only the last one, and we may want to correcct it once
>> this series solidifies as a separate "bugfix" change on top.
> 
> This is a tangent, but I _think_ (didn't check, though) "git am -s"
> implements this incorrrectly.  Just another LHF somebody may want to
> take a look.

(I haven't checked the 'git am -s' behavior, but ...)

One distinction between commit, cherry-pick, am, and format-patch is
that the first three are related to importing commits _into_ your own
repository while format-patch is related to exporting patches _from_
your repository.

Not sure if an "exporting" operation should be treated differently from
an "importing" operation and mean "add my sign-off only if I did not
previously do so when I did commit, cherry-pick, or am" or whether it
should mean the same thing i.e. "append my sign-off, unless it's already
last".

Just pointing something out that may or may not be useful.

Hmm, actually, this series could provide a data point.  When I submitted
the first series, I used 'format-patch -s' to append my sob.  When
Jonathan reviewed the series, he provided Acked-by and Reviewed-by which
I collected and added as I reworked the series.  When I added Jonathan's
Ack's/Rev-by's, I _appended_ them to the commits that I had already
submitted, so they appeared _after_ my own sob.  When I submitted the
later iterations of the series, I probably used 'format-patch -s' again
and I of course did not want an additional sob to be appended after
Jonathan's Acks.

-Brandon


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

^ permalink raw reply

* Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect
From: Andreas Mohr @ 2013-02-10  0:23 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Andreas Mohr, Michael J Gruber, git
In-Reply-To: <7vy5ext60o.fsf@alter.siamese.dyndns.org>

On Sat, Feb 09, 2013 at 03:35:35PM -0800, Junio C Hamano wrote:
> Andreas Mohr <andi@lisas.de> writes:
> > The main point of my mail was to stretch the (whether actually intended)
> > *perceived* start <-> stop symmetry
> 
> Actually, in that sense, I do no think finish is exactly a good
> wording.  The majority of use case would be to finish up after you
> found the sole culprit, so in that sense "finish" is not too bad,
> but in general, when you "reset", there is not necessarily any
> symmmetry with "start".  We should definitely not be giving you an
> illusion that there is one by using "stop" [*1*].

Yeah, of course, but the whole point was that the *user* will *directly*
and *immediately* mentally go from a bisect "start" parameter to "stop",
and end up failing to find it.
Thus the "stop" *KEYWORD* *has* to be mentioned in the man page
(even if only to then expressly state that reset is not quite about "stop"iing
things).

> *1* another reason to avoid "stop" is that it could mean "I stop
> here for now, to later come back and start digging again from
> there", which is not "reset" is about at all.

Such reasons for not listing "stop" might even be stronger
than the reason of
users being required to successfully look up the symmetric "stop" keyword.
If that was decided to be the case, then "stop" would indeed have to be
omitted in the man page - to the detriments of usability.

Thanks,

Andreas Mohr

^ permalink raw reply

* [PATCH] mergetools,difftool: fix printf usage
From: David Aguilar @ 2013-02-10  1:21 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Asheesh Laroia

Prevent environment variables and filenames from masquerading
as format strings for printf.

Reported-by: Asheesh Laroia <asheesh@asheesh.org>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
 git-difftool--helper.sh | 2 +-
 mergetools/p4merge      | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
index 3d0fe0c..b00ed95 100755
--- a/git-difftool--helper.sh
+++ b/git-difftool--helper.sh
@@ -40,7 +40,7 @@ launch_merge_tool () {
 	# the user with the real $MERGED name before launching $merge_tool.
 	if should_prompt
 	then
-		printf "\nViewing: '$MERGED'\n"
+		printf "\nViewing: '%s'\n" "$MERGED"
 		if use_ext_cmd
 		then
 			printf "Launch '%s' [Y/n]: " \
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 52f7c8f..8a36916 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -30,5 +30,5 @@ create_empty_file () {
 	empty_file="${TMPDIR:-/tmp}/git-difftool-p4merge-empty-file.$$"
 	>"$empty_file"
 
-	printf "$empty_file"
+	printf "%s" "$empty_file"
 }
-- 
1.8.1.3.696.gfd94e3d.dirty

^ permalink raw reply related

* Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect
From: Jonathan Nieder @ 2013-02-10  1:49 UTC (permalink / raw)
  To: Michael J Gruber; +Cc: git, Junio C Hamano, Andreas Mohr
In-Reply-To: <5e23d4c420f150b700dd5100bffb38d32f874200.1360439176.git.git@drmicha.warpmail.net>

Hi,

Michael J Gruber wrote:

> "reset" can be easily misunderstood as resetting a bisect session to its
> start without finishing it. Clarify that it actually finishes the bisect
> session.

FWIW,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

Addressing Andreas's original concern about the discoverability of
'git bisect reset' would presumably require doing two more things:

 1. adding an example of the normal bisection workflow to the EXAMPLES
    section

 2. training users to look to the EXAMPLES section

That is, something like the below.  But I'm not happy with it, because
it just runs over the same material as the current Description
section.  Maybe the current tutorial material could be moved to
examples and replaced with something terser that fleshes out the
descriptions in "git bisect -h" output.  What do you think?

diff --git i/Documentation/git-bisect.txt w/Documentation/git-bisect.txt
index e4f46bc1..b89abd78 100644
--- i/Documentation/git-bisect.txt
+++ w/Documentation/git-bisect.txt
@@ -356,6 +356,54 @@ $ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
 This shows that you can do without a run script if you write the test
 on a single line.
 
+* Bisect to find which patch caused a boot failure:
++
+Install a recent kernel:
++
+------------
+$ cd ~/src/linux
+$ git checkout origin/master
+$ make deb-pkg # or binrpm-pkg, or tar-pkg
+$ dpkg -i ../<name of package> # as root (or rpm -i, or tar -C / -xf)
+$ reboot # as root
+------------
++
+Hopefully it fails to boot, so tell git so and begin bisection:
++
+------------
+$ cd ~/src/linux
+$ git bisect start HEAD v3.2 # assuming 3.2 works fine
+-------------
++
+A candidate revision to test is automatically checked out.
+Test it:
++
+-------------
+$ make deb-pkg # or binrpm-pkg, or tar-pkg
+$ dpkg -i ../<name of package> # as root (or rpm -i, or tar -C / -xf)
+$ reboot # as root
+-------------
++
+Record the result:
++
+-------------
+$ cd ~/src/linux
+$ git bisect good # if it booted correctly
+$ git bisect bad # if it failed to boot
+$ git bisect skip # if some other bug made it hard to test
+-------------
++
+Repeat until bored or git prints the "first bad commit".  When
+done:
++
+-------------
+$ git bisect log >log # let others pick up where you left off
+$ git bisect reset HEAD # exit the bisecting state
+-------------
++
+At any step, you can run `git bisect visualize` to watch the
+regression range narrowing.
+
 * Locate a good region of the object graph in a damaged repository
 +
 ------------

^ permalink raw reply related

* Re: Feature request: Allow extracting revisions into directories
From: Junio C Hamano @ 2013-02-10  3:45 UTC (permalink / raw)
  To: Robert Clausecker; +Cc: git, Phil Hord
In-Reply-To: <7vehgpum7n.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

> I am not Phil, but if you ask me, I think it is borderline between
> "meh" and "no way we would give a short-and-sweet -i to something
> like this".

I think one reason it was "meh" for me is that we never did an
equivalent of "cvs export" and "svn export", primarily because
we had "tar-tree" (aka "archive --format=tar") first, and it was
sufficient to pipe its outputto "tar xf -" if somebody wanted to do
the non-existent "git export".  Also "tar-tree" was more useful for
people who wanted to eventually want to have a tarball (you can
first "export" and then "tar cf" the resulting directory).

But I think it is fine to add "git export <revision> <directory>",
which may look like this, perhaps.

	#!/bin/sh
	# git export <rev> <directory>
	rev=${1?revision} dir=${2?directory}
	. $(git --exec-path)/git-sh-setup

        mkdir -p "$dir" || exit
        git archive --format=tar "$rev" |
        tar Cxf "$dir" -

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox