* Re: [PATCH 2/2] git-svn: handle SVN merges from revisions past the tip of the branch
From: Sam Vilain @ 2009-11-13 0:47 UTC (permalink / raw)
To: Toby Allsopp; +Cc: git, Eric Wong
In-Reply-To: <871vk35o86.fsf@navakl084.mitacad.com>
Toby Allsopp wrote:
> When recording the revisions that it has merged, SVN sets the top
> revision to be the latest revision in the repository, which is not
> necessarily a revision on the branch that is being merged from. When
> it is not on the branch, git-svn fails to add the extra parent to
> represent the merge because it relies on finding the commit on the
> branch that corresponds to the top of the SVN merge range.
I thought, "that sounds like he's repeating himself, wait a sec..."
> -test_expect_failure 'represent svn merges with intervening commits' "
> +test_expect_success 'represent svn merges with intervening commits' "
> [ `git cat-file commit HEAD | grep parent | wc -l` -eq 2 ]
> "
So you made a failing test and then added the implementation for it?
Interesting strategy :). I'd probably not repeat the same sentence
twice though.
Thanks for contributing this. There might be other bugs too, especially
when upstream has a more complicated merge hierarchy ... apparently svn
tends to get it wrong, so checking for all commits might not work in
that case.
It would be nice if "dcommit" could make these commits, too...
Sam
^ permalink raw reply
* [RFC/PATCH 0/3] gitweb: Refactor common parts of log-like views
From: Jakub Narebski @ 2009-11-13 1:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
This series extracts common parts of log-like views: 'log', 'shortlog'
and 'history' view, into git_log_generic() subroutine. This
unification of code reduces code duplication, and brings features such
as limiting the list of commits displayed using $hash_parent{,_base}
from 'shortlog' view (added in ec3e97b (gitweb: shortlog now also
obeys $hash_parent, 2008-08-08)).
I have tested this series a bit (it passes both t9500 and t9501 test),
but I didn't test all the corner cases.
This series is preparation for even more refactoring planned, to make
it easier to introduce new log-like action (new log formats). It
doesn't include (for now) the 'search' view, neither in message search
not in pickaxe search form.
Jakub Narebski (3):
gitweb: Refactor 'log' action generation, adding git_log_body()
gitweb: Refactor common parts of 'log' and 'shortlog' views
gitweb: Make 'history' view (re)use git_log_generic()
gitweb/gitweb.perl | 269 +++++++++++++++++++++-------------------------------
1 files changed, 110 insertions(+), 159 deletions(-)
--
Jakub Narebski
^ permalink raw reply
* [PATCH 2/3] gitweb: Refactor common parts of 'log' and 'shortlog' views
From: Jakub Narebski @ 2009-11-13 1:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1258074134-27011-1-git-send-email-jnareb@gmail.com>
Put the common parts of git_log and git_shortlog into git_log_generic
subroutine: git_log and git_shortlog are now thin wrappers calling
git_log_generic with appropriate arguments.
The unification of code responsible for 'log' and 'shorlog' actions
lead to the following changes in gitweb output
* 'tree' link in page_nav now uses $hash parameter, as was the case
for 'shortlog' but not for 'log'
* 'log' view now respect $hash_parent limiting, like 'shortlog' did
* 'log' view doesn't have special case for empty list anymore, and it
always uses page_header linking to summary view, like 'shortlog'
did.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 72 ++++++++++++++-------------------------------------
1 files changed, 20 insertions(+), 52 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 68dbd9e..14661cc 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5336,7 +5336,9 @@ sub git_snapshot {
close $fd;
}
-sub git_log {
+sub git_log_generic {
+ my ($fmt_name, $body_subr) = @_;
+
my $head = git_get_head_hash($project);
if (!defined $hash) {
$hash = $head;
@@ -5346,16 +5348,21 @@ sub git_log {
}
my $refs = git_get_references();
- my @commitlist = parse_commits($hash, 101, (100 * $page));
+ my $commit_hash = $hash;
+ if (defined $hash_parent) {
+ $commit_hash = "$hash_parent..$hash";
+ }
+ my @commitlist = parse_commits($commit_hash, 101, (100 * $page));
- my $paging_nav = format_paging_nav('log', $hash, $head, $page, $#commitlist >= 100);
- my $next_link;
+ my $paging_nav = format_paging_nav($fmt_name, $hash, $head,
+ $page, $#commitlist >= 100);
+ my $next_link = '';
if ($#commitlist >= 100) {
$next_link =
$cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
}
- my ($patch_max) = gitweb_get_feature('patches');
+ my $patch_max = gitweb_get_feature('patches');
if ($patch_max) {
if ($patch_max < 0 || @commitlist <= $patch_max) {
$paging_nav .= " ⋅ " .
@@ -5365,20 +5372,18 @@ sub git_log {
}
git_header_html();
- git_print_page_nav('log','', $hash,undef,undef, $paging_nav);
-
- if (!@commitlist) {
- my %co = parse_commit($hash);
-
- git_print_header_div('summary', $project);
- print "<div class=\"page_body\"> Last change $co{'age_string'}.<br/><br/></div>\n";
- }
+ git_print_page_nav($fmt_name,'', $hash,$hash,$hash, $paging_nav);
+ git_print_header_div('summary', $project);
- git_log_body(\@commitlist, 0, 99, $refs, $next_link);
+ $body_subr->(\@commitlist, 0, 99, $refs, $next_link);
git_footer_html();
}
+sub git_log {
+ git_log_generic('log', \&git_log_body);
+}
+
sub git_commit {
$hash ||= $hash_base || "HEAD";
my %co = parse_commit($hash)
@@ -6242,44 +6247,7 @@ EOT
}
sub git_shortlog {
- my $head = git_get_head_hash($project);
- if (!defined $hash) {
- $hash = $head;
- }
- if (!defined $page) {
- $page = 0;
- }
- my $refs = git_get_references();
-
- my $commit_hash = $hash;
- if (defined $hash_parent) {
- $commit_hash = "$hash_parent..$hash";
- }
- my @commitlist = parse_commits($commit_hash, 101, (100 * $page));
-
- my $paging_nav = format_paging_nav('shortlog', $hash, $head, $page, $#commitlist >= 100);
- my $next_link = '';
- if ($#commitlist >= 100) {
- $next_link =
- $cgi->a({-href => href(-replay=>1, page=>$page+1),
- -accesskey => "n", -title => "Alt-n"}, "next");
- }
- my $patch_max = gitweb_check_feature('patches');
- if ($patch_max) {
- if ($patch_max < 0 || @commitlist <= $patch_max) {
- $paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>"patches", -replay=>1)},
- "patches");
- }
- }
-
- git_header_html();
- git_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
- git_print_header_div('summary', $project);
-
- git_shortlog_body(\@commitlist, 0, 99, $refs, $next_link);
-
- git_footer_html();
+ git_log_generic('shortlog', \&git_shortlog_body);
}
## ......................................................................
--
1.6.5
^ permalink raw reply related
* [PATCH 1/3] gitweb: Refactor 'log' action generation, adding git_log_body()
From: Jakub Narebski @ 2009-11-13 1:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1258074134-27011-1-git-send-email-jnareb@gmail.com>
Put the main part of 'log' view generation into git_log_body,
similarly how it is done for 'shortlog' and 'history' views (and
also for 'tags' and 'heads' views).
This is preparation for extracting common code between 'log',
'shortlog' and 'history' actions.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is pure refactoring: output should change.
gitweb/gitweb.perl | 81 ++++++++++++++++++++++++++++++---------------------
1 files changed, 48 insertions(+), 33 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e4cbfc3..68dbd9e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4361,6 +4361,46 @@ sub git_project_list_body {
print "</table>\n";
}
+sub git_log_body {
+ # uses global variable $project
+ my ($commitlist, $from, $to, $refs, $extra) = @_;
+
+ $from = 0 unless defined $from;
+ $to = $#{$commitlist} if (!defined $to || $#{$commitlist} < $to);
+
+ for (my $i = 0; $i <= $to; $i++) {
+ my %co = %{$commitlist->[$i]};
+ next if !%co;
+ my $commit = $co{'id'};
+ my $ref = format_ref_marker($refs, $commit);
+ my %ad = parse_date($co{'author_epoch'});
+ git_print_header_div('commit',
+ "<span class=\"age\">$co{'age_string'}</span>" .
+ esc_html($co{'title'}) . $ref,
+ $commit);
+ print "<div class=\"title_text\">\n" .
+ "<div class=\"log_link\">\n" .
+ $cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") .
+ " | " .
+ $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") .
+ " | " .
+ $cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree") .
+ "<br/>\n" .
+ "</div>\n";
+ git_print_authorship(\%co, -tag => 'span');
+ print "<br/>\n</div>\n";
+
+ print "<div class=\"log_body\">\n";
+ git_print_log($co{'comment'}, -final_empty_line=> 1);
+ print "</div>\n";
+ }
+ if ($extra) {
+ print "<div class=\"page_nav\">\n";
+ print "$extra\n";
+ print "</div>\n";
+ }
+}
+
sub git_shortlog_body {
# uses global variable $project
my ($commitlist, $from, $to, $refs, $extra) = @_;
@@ -5309,7 +5349,12 @@ sub git_log {
my @commitlist = parse_commits($hash, 101, (100 * $page));
my $paging_nav = format_paging_nav('log', $hash, $head, $page, $#commitlist >= 100);
-
+ my $next_link;
+ if ($#commitlist >= 100) {
+ $next_link =
+ $cgi->a({-href => href(-replay=>1, page=>$page+1),
+ -accesskey => "n", -title => "Alt-n"}, "next");
+ }
my ($patch_max) = gitweb_get_feature('patches');
if ($patch_max) {
if ($patch_max < 0 || @commitlist <= $patch_max) {
@@ -5328,39 +5373,9 @@ sub git_log {
git_print_header_div('summary', $project);
print "<div class=\"page_body\"> Last change $co{'age_string'}.<br/><br/></div>\n";
}
- my $to = ($#commitlist >= 99) ? (99) : ($#commitlist);
- for (my $i = 0; $i <= $to; $i++) {
- my %co = %{$commitlist[$i]};
- next if !%co;
- my $commit = $co{'id'};
- my $ref = format_ref_marker($refs, $commit);
- my %ad = parse_date($co{'author_epoch'});
- git_print_header_div('commit',
- "<span class=\"age\">$co{'age_string'}</span>" .
- esc_html($co{'title'}) . $ref,
- $commit);
- print "<div class=\"title_text\">\n" .
- "<div class=\"log_link\">\n" .
- $cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") .
- " | " .
- $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") .
- " | " .
- $cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree") .
- "<br/>\n" .
- "</div>\n";
- git_print_authorship(\%co, -tag => 'span');
- print "<br/>\n</div>\n";
- print "<div class=\"log_body\">\n";
- git_print_log($co{'comment'}, -final_empty_line=> 1);
- print "</div>\n";
- }
- if ($#commitlist >= 100) {
- print "<div class=\"page_nav\">\n";
- print $cgi->a({-href => href(-replay=>1, page=>$page+1),
- -accesskey => "n", -title => "Alt-n"}, "next");
- print "</div>\n";
- }
+ git_log_body(\@commitlist, 0, 99, $refs, $next_link);
+
git_footer_html();
}
--
1.6.5
^ permalink raw reply related
* [PATCH 3/3] gitweb: Make 'history' view (re)use git_log_generic()
From: Jakub Narebski @ 2009-11-13 1:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1258074134-27011-1-git-send-email-jnareb@gmail.com>
Make git_history use git_log_generic, passing git_history_body as one
of its paramaters. This required changes to git_log_generic, in
particular passing more things as parameters.
While refactoring common code of 'log', 'shortlog' and 'history' view,
we did unify pagination, using always the form used by 'history' view,
namely
first * prev * next
in place of
HEAD * prev * next
used by 'log' and 'shortlog' views.
The 'history' view now supports commit limiting via 'hpb' parameter,
similarly to 'shortlog' (and 'log') view. Performance of 'history'
view got improved a bit, as it doesn't run git_get_hash_by_path for
"current" version in a loop. Error detection and reporting for
'history' view changed a bit.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 146 ++++++++++++++++++++-------------------------------
1 files changed, 57 insertions(+), 89 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 14661cc..5cfa507 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3363,22 +3363,18 @@ sub git_print_page_nav {
}
sub format_paging_nav {
- my ($action, $hash, $head, $page, $has_next_link) = @_;
+ my ($action, $page, $has_next_link) = @_;
my $paging_nav;
- if ($hash ne $head || $page) {
- $paging_nav .= $cgi->a({-href => href(action=>$action)}, "HEAD");
- } else {
- $paging_nav .= "HEAD";
- }
-
if ($page > 0) {
- $paging_nav .= " ⋅ " .
+ $paging_nav .=
+ $cgi->a({-href => href(-replay=>1, page=>undef)}, "first") .
+ " ⋅ " .
$cgi->a({-href => href(-replay=>1, page=>$page-1),
-accesskey => "p", -title => "Alt-p"}, "prev");
} else {
- $paging_nav .= " ⋅ prev";
+ $paging_nav .= "first ⋅ prev";
}
if ($has_next_link) {
@@ -4447,7 +4443,8 @@ sub git_shortlog_body {
sub git_history_body {
# Warning: assumes constant type (blob or tree) during history
- my ($commitlist, $from, $to, $refs, $hash_base, $ftype, $extra) = @_;
+ my ($commitlist, $from, $to, $refs, $extra,
+ $file_name, $file_hash, $ftype) = @_;
$from = 0 unless defined $from;
$to = $#{$commitlist} unless (defined $to && $to <= $#{$commitlist});
@@ -4481,7 +4478,7 @@ sub git_history_body {
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff");
if ($ftype eq 'blob') {
- my $blob_current = git_get_hash_by_path($hash_base, $file_name);
+ my $blob_current = $file_hash;
my $blob_parent = git_get_hash_by_path($commit, $file_name);
if (defined $blob_current && defined $blob_parent &&
$blob_current ne $blob_parent) {
@@ -5337,25 +5334,48 @@ sub git_snapshot {
}
sub git_log_generic {
- my ($fmt_name, $body_subr) = @_;
+ my ($fmt_name, $body_subr, $base, $parent, $file_name, $file_hash) = @_;
my $head = git_get_head_hash($project);
- if (!defined $hash) {
- $hash = $head;
+ if (!defined $base) {
+ $base = $head;
}
if (!defined $page) {
$page = 0;
}
my $refs = git_get_references();
- my $commit_hash = $hash;
- if (defined $hash_parent) {
- $commit_hash = "$hash_parent..$hash";
+ my $commit_hash = $base;
+ if (defined $parent) {
+ $commit_hash = "$parent..$base";
+ }
+ my @commitlist =
+ parse_commits($commit_hash, 101, (100 * $page),
+ defined $file_name ? ($file_name, "--full-history") : ());
+
+ my $ftype;
+ if (!defined $file_hash && defined $file_name) {
+ # some commits could have deleted file in question,
+ # and not have it in tree, but one of them has to have it
+ for (my $i = 0; $i < @commitlist; $i++) {
+ $file_hash = git_get_hash_by_path($commitlist[$i]{'id'}, $file_name);
+ last if defined $file_hash;
+ }
+ }
+ if (defined $file_hash) {
+ $ftype = git_get_type($file_hash);
+ }
+ if (defined $file_name && !defined $ftype) {
+ die_error(500, "Unknown type of object");
+ }
+ my %co;
+ if (defined $file_name) {
+ %co = parse_commit($base)
+ or die_error(404, "Unknown commit object");
}
- my @commitlist = parse_commits($commit_hash, 101, (100 * $page));
- my $paging_nav = format_paging_nav($fmt_name, $hash, $head,
- $page, $#commitlist >= 100);
+
+ my $paging_nav = format_paging_nav($fmt_name, $page, $#commitlist >= 100);
my $next_link = '';
if ($#commitlist >= 100) {
$next_link =
@@ -5363,7 +5383,7 @@ sub git_log_generic {
-accesskey => "n", -title => "Alt-n"}, "next");
}
my $patch_max = gitweb_get_feature('patches');
- if ($patch_max) {
+ if ($patch_max && !defined $file_name) {
if ($patch_max < 0 || @commitlist <= $patch_max) {
$paging_nav .= " ⋅ " .
$cgi->a({-href => href(action=>"patches", -replay=>1)},
@@ -5373,15 +5393,23 @@ sub git_log_generic {
git_header_html();
git_print_page_nav($fmt_name,'', $hash,$hash,$hash, $paging_nav);
- git_print_header_div('summary', $project);
+ if (defined $file_name) {
+ git_print_header_div('commit', esc_html($co{'title'}), $base);
+ } else {
+ git_print_header_div('summary', $project)
+ }
+ git_print_page_path($file_name, $ftype, $hash_base)
+ if (defined $file_name);
- $body_subr->(\@commitlist, 0, 99, $refs, $next_link);
+ $body_subr->(\@commitlist, 0, 99, $refs, $next_link,
+ $file_name, $file_hash, $ftype);
git_footer_html();
}
sub git_log {
- git_log_generic('log', \&git_log_body);
+ git_log_generic('log', \&git_log_body,
+ $hash, $hash_parent);
}
sub git_commit {
@@ -5920,70 +5948,9 @@ sub git_patches {
}
sub git_history {
- if (!defined $hash_base) {
- $hash_base = git_get_head_hash($project);
- }
- if (!defined $page) {
- $page = 0;
- }
- my $ftype;
- my %co = parse_commit($hash_base)
- or die_error(404, "Unknown commit object");
-
- my $refs = git_get_references();
- my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
-
- my @commitlist = parse_commits($hash_base, 101, (100 * $page),
- $file_name, "--full-history")
- or die_error(404, "No such file or directory on given branch");
-
- if (!defined $hash && defined $file_name) {
- # some commits could have deleted file in question,
- # and not have it in tree, but one of them has to have it
- for (my $i = 0; $i <= @commitlist; $i++) {
- $hash = git_get_hash_by_path($commitlist[$i]{'id'}, $file_name);
- last if defined $hash;
- }
- }
- if (defined $hash) {
- $ftype = git_get_type($hash);
- }
- if (!defined $ftype) {
- die_error(500, "Unknown type of object");
- }
-
- my $paging_nav = '';
- if ($page > 0) {
- $paging_nav .=
- $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
- file_name=>$file_name)},
- "first");
- $paging_nav .= " ⋅ " .
- $cgi->a({-href => href(-replay=>1, page=>$page-1),
- -accesskey => "p", -title => "Alt-p"}, "prev");
- } else {
- $paging_nav .= "first";
- $paging_nav .= " ⋅ prev";
- }
- my $next_link = '';
- if ($#commitlist >= 100) {
- $next_link =
- $cgi->a({-href => href(-replay=>1, page=>$page+1),
- -accesskey => "n", -title => "Alt-n"}, "next");
- $paging_nav .= " ⋅ $next_link";
- } else {
- $paging_nav .= " ⋅ next";
- }
-
- git_header_html();
- git_print_page_nav('history','', $hash_base,$co{'tree'},$hash_base, $paging_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
- git_print_page_path($file_name, $ftype, $hash_base);
-
- git_history_body(\@commitlist, 0, 99,
- $refs, $hash_base, $ftype, $next_link);
-
- git_footer_html();
+ git_log_generic('history', \&git_history_body,
+ $hash_base, $hash_parent_base,
+ $file_name, $hash);
}
sub git_search {
@@ -6247,7 +6214,8 @@ EOT
}
sub git_shortlog {
- git_log_generic('shortlog', \&git_shortlog_body);
+ git_log_generic('shortlog', \&git_shortlog_body,
+ $hash, $hash_parent);
}
## ......................................................................
--
1.6.5
^ permalink raw reply related
* Re: [PATCH 2/2] git-svn: handle SVN merges from revisions past the tip of the branch
From: Toby Allsopp @ 2009-11-13 1:03 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Eric Wong
In-Reply-To: <4AFCAC9C.9020305@vilain.net>
On Fri, Nov 13 2009, Sam Vilain wrote:
> Toby Allsopp wrote:
> > When recording the revisions that it has merged, SVN sets the top
> > revision to be the latest revision in the repository, which is not
> > necessarily a revision on the branch that is being merged from. When
> > it is not on the branch, git-svn fails to add the extra parent to
> > represent the merge because it relies on finding the commit on the
> > branch that corresponds to the top of the SVN merge range.
>
> I thought, "that sounds like he's repeating himself, wait a sec..."
Hmm, it makes perfect sense to me :-) Does the explanation in 1/2 make
more sense?
The first sentence describes what Subversion does, the second what
git-svn does in response.
> Thanks for contributing this. There might be other bugs too, especially
> when upstream has a more complicated merge hierarchy ... apparently svn
> tends to get it wrong, so checking for all commits might not work in
> that case.
Oh yes, SVN gets the merges wrong in an alarming number of cases, it's
really shocking. I only stay sane at work because I tell myself that
SVN is making the case for git for me :-)
> It would be nice if "dcommit" could make these commits, too...
Yes.
Toby.
^ permalink raw reply
* [PATCH] Update 'git remote' usage and man page to match.
From: Tim Henigan @ 2009-11-13 1:15 UTC (permalink / raw)
To: gitster; +Cc: git
This commit:
1) Removes documentation of '--verbose' from the synopsis portion
of the usage string since it is a general option.
2) Removes the 'remote' option from 'git remote update' in the
man page. This option had already been removed from the usage
string in the code, but the man page was not updated to match.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This is a resend of the patch at:
http://article.gmane.org/gmane.comp.version-control.git/132732
I forgot to include 'gitster at pobox dot com' on the original patch.
No changes were made to the patch itself.
Sorry for the noise.
Documentation/git-remote.txt | 4 ++--
builtin-remote.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 82a3d29..32ff95b 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -9,14 +9,14 @@ git-remote - manage set of tracked repositories
SYNOPSIS
--------
[verse]
-'git remote' [-v | --verbose]
+'git remote'
'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
'git remote rename' <old> <new>
'git remote rm' <name>
'git remote set-head' <name> [-a | -d | <branch>]
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
-'git remote update' [-p | --prune] [group | remote]...
+'git remote update' [-p | --prune] [group]...
DESCRIPTION
-----------
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..3756e91 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -8,14 +8,14 @@
#include "refs.h"
static const char * const builtin_remote_usage[] = {
- "git remote [-v | --verbose]",
+ "git remote",
"git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
"git remote rename <old> <new>",
"git remote rm <name>",
"git remote set-head <name> [-a | -d | <branch>]",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group]",
+ "git remote update [-p | --prune] [group]",
NULL
};
--
1.6.5.2.180.gc5b3e.dirty
^ permalink raw reply related
* Re: [PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found
From: Jonathan Nieder @ 2009-11-13 4:07 UTC (permalink / raw)
To: Jan Krüger
Cc: Jeff King, Jan Nieuwenhuizen, Tomas Carnecky, git list,
Junio C Hamano
In-Reply-To: <20091112170814.1858aba4@perceptron>
Jan Krüger wrote:
> Subject: [PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found
s/error handling/error message/. :)
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -91,45 +91,56 @@ error_on_no_merge_candidates () {
[...]
> if [ $# -gt 1 ]; then
> - echo "There are no candidates for merging in the refs that you just fetched."
> + echo "There are no candidates for using the refs that you just fetched."
> echo "Generally this means that you provided a wildcard refspec which had no"
> echo "matches on the remote end."
This sounds a little awkward to me, maybe because all the remote refs
are being used to populate the remotes/<remote>/* hierarchy.
I’m trying to come up with an alternative wording, but it is hard:
* Merging and rebasing are about incorporating the remote history
into our own, so how about something like "... no candidates for
incorporating from the refs ..."?
* Maybe one is using 'git pull' to update. "There are no
candidates to use for an update among the refs that you just
fetched."
* Or: "There are no upstreams to local branches among the refs that
you just fetched."
I like the third of these best, but I hope you can do better.
> elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
> echo "You asked to pull from the remote '$1', but did not specify"
> - echo "a branch to merge. Because this is not the default configured remote"
> + echo "a branch to use. Because this is not the default configured remote"
Maybe just "... did not specify a branch."?
> echo "for your current branch, you must specify a branch on the command line."
> elif [ -z "$curr_branch" ]; then
> echo "You are not currently on a branch, so I cannot use any"
> echo "'branch.<branchname>.merge' in your configuration file."
> - echo "Please specify which branch you want to merge on the command"
> + echo "Please specify which branch you want to use on the command"
s/branch/remote branch/? The reader might worry that the command is
going to try to re-attach his HEAD.
The rest of your patch looks good to me. Thanks for working on this.
Jonathan
^ permalink raw reply
* Re: Git in next is broken
From: Nicolas Pitre @ 2009-11-13 4:50 UTC (permalink / raw)
To: Julian Phillips; +Cc: René Scharfe, git
In-Reply-To: <alpine.LNX.2.00.0911122239150.6967@reaper.quantumfyre.co.uk>
On Thu, 12 Nov 2009, Julian Phillips wrote:
> On Thu, 12 Nov 2009, Ren? Scharfe wrote:
>
> > Nicolas Pitre schrieb:
> > > Simply issuing a "git fetch" in my copy of git.git makes glibc complain
> > > with this:
> > >
> > > *** glibc detected *** git: corrupted double-linked list:
> > > 0x0000000000974180 ***
> > >
> > > The gdb backtrace is:
> > >
> > > (gdb) bt
> > > #0 0x0000003c76632f05 in raise () from /lib64/libc.so.6
> > > #1 0x0000003c76634a73 in abort () from /lib64/libc.so.6
> > > #2 0x0000003c76672438 in __libc_message () from /lib64/libc.so.6
> > > #3 0x0000003c76677ec8 in malloc_printerr () from /lib64/libc.so.6
> > > #4 0x0000003c7667a23e in _int_free () from /lib64/libc.so.6
> > > #5 0x0000003c7667a486 in free () from /lib64/libc.so.6
> > > #6 0x0000000000493f3f in ref_remove_duplicates (ref_map=0x7562b0)
> > > at remote.c:756
> > > #7 0x0000000000424afc in get_ref_map () at builtin-fetch.c:165
> > > #8 do_fetch () at builtin-fetch.c:644
> > > #9 cmd_fetch (argc=<value optimized out>, argv=0x7fffffffe6a0,
> > > prefix=<value optimized out>) at builtin-fetch.c:754
> > > #10 0x0000000000403d83 in run_builtin () at git.c:251
> > > #11 handle_internal_command (argc=1, argv=0x7fffffffe6a0) at git.c:396
> > > #12 0x0000000000403f2d in run_argv () at git.c:438
> > > #13 main (argc=1, argv=0x7fffffffe6a0) at git.c:509
> > >
> > > Bisection reveals the following culprit:
> > >
> > > commit 73cf0822b2a4ffa7ad559d1f0772e39718fc7776
> > > Author: Julian Phillips <julian@quantumfyre.co.uk>
> > > Date: Sun Oct 25 21:28:11 2009 +0000
> > >
> > > remote: Make ref_remove_duplicates faster for large numbers of refs
> >
> > Can't reproduce because I don't know how to create duplicate refs, but does
> > the following help?
Nope.
> > remote.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/remote.c b/remote.c
> > index 4f9f0cc..10cc985 100644
> > --- a/remote.c
> > +++ b/remote.c
> > @@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
> > prev->next = ref_map->next;
> > free(ref_map->peer_ref);
> > free(ref_map);
> > + ref_map = next;
>
> You don't need this line (this is taken care of in the for(...)).
>
> > + continue;
>
> Ack. This one however, you do need. Good catch.
Without the "ref_map = next" there is no change: glibc still complains
about corruption and abort the execution. With the "ref_map = next"
then git simply segfaults.
I simply have zero time to investigate the issue myself now
unfortunately.
Nicolas
^ permalink raw reply
* Re: ks/precompute-completion
From: Stephen Boyd @ 2009-11-13 6:40 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <20091111220832.GA31620@progeny.tock>
Jonathan Nieder wrote:
>
> As a distro user, I don't think I would be able to use it until there
> is a command to update the installed completion, to call after adding
> a new git command to my $PATH. This could mean:
>
> - git-completion.bash.generate learns to read the .in file and
> write the completion script to arbitrary paths (or just always
> uses stdin and stdout?)
>
> - distros install git-completion.bash.{generate,in} to /usr/share/git-core
>
> - distros install a simple completion script to /etc/bash_completion.d
> that passes the buck, e.g.
>
> <snip scripts>
>
> Thoughts?
I'm confused. Shouldn't your distro take care of updating the completion
for you? And wouldn't update-git-completion be more suited as part of a
makefile if it was needed at all?
^ permalink raw reply
* error while cloning a remote repository
From: Shameem Ahamed @ 2009-11-13 6:38 UTC (permalink / raw)
To: git
Hi,
I ran in to a warning message while cloning a remote repository.
The message is
warning: remote HEAD refers to nonexistent ref, unable to checkout.
After the cloning i couldn't see any remote files. The .git folder is created successfully.
Regards,
Shameem
^ permalink raw reply
* Re: ks/precompute-completion
From: Jonathan Nieder @ 2009-11-13 7:06 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <4AFCFF50.5080401@gmail.com>
Stephen Boyd wrote:
> Jonathan Nieder wrote:
>>
>>As a distro user, I don't think I would be able to use it until there
>>is a command to update the installed completion, to call after adding
>>a new git command to my $PATH. This could mean:
[...]
> I'm confused. Shouldn't your distro take care of updating the
> completion for you? And wouldn't update-git-completion be more
> suited as part of a makefile if it was needed at all?
The problem is that I have git commands the distro did not install in
my $PATH. For example, I currently have git-new-workdir in ~/bin, and
once I bzr-fastexport works a little better, I will install git-bzr.
Even without such commands, in many distributions the completion
should not be one size fits all, since git-svn (for example) belongs
to a different package.
I would expect the distribution to take care of populating the initial
completion list and updating it on upgrades.
Jonathan
^ permalink raw reply
* Re: ks/precompute-completion
From: Stephen Boyd @ 2009-11-13 7:12 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <20091113070652.GA3907@progeny.tock>
Jonathan Nieder wrote:
> Stephen Boyd wrote:
>> I'm confused. Shouldn't your distro take care of updating the
>> completion for you? And wouldn't update-git-completion be more
>> suited as part of a makefile if it was needed at all?
>
> The problem is that I have git commands the distro did not install in
> my $PATH. For example, I currently have git-new-workdir in ~/bin, and
> once I bzr-fastexport works a little better, I will install git-bzr.
>
> Even without such commands, in many distributions the completion
> should not be one size fits all, since git-svn (for example) belongs
> to a different package
Ah ok. I think this proves even more that pregenerating the completion
is a bad idea. With dynamic population we don't have these problems and
it only takes 250ms more to load on a P3 700Mhz.
Maybe we should try and speedup 'git help -a' and 'git merge -s help'
instead? Perhaps options for the command/porcelain lists and available
strategies formatted for script consumption? I doubt it will be as fast
as compiling, but every bit helps apparently.
Side Note: Running git merge -s help outside a git repository fails, so
caching of the merge strategies isn't very effective.
^ permalink raw reply
* Re: git status internals and line endings
From: Marc Strapetz @ 2009-11-13 8:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091113001547.GB28836@sigill.intra.peff.net>
> Sounds like the core.autocrlf setting (see "git help config"), which I
> believe is set by default on Windows.
I have checked both $GIT_DIR/config and ~/.gitconfig and autocrlf has
not been set. I have then set autocrlf = false for the Windows
repository and still the file didn't show up as modified. On Linux, I've
added autocrlf = true (resp. autocrlf = input) for the repository and
still the file shows up as modified. Not that I don't like this
behavior, but I don't understand it :) Windows Git version is 1.6.5.1,
Linux version is 1.6.3.3.
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Jeff King wrote:
> On Thu, Nov 12, 2009 at 09:32:14PM +0100, Marc Strapetz wrote:
>
>> On Linux, file1 and file3 are reported as modified -- as I would expect.
>> The surprise is on Windows: here only file1 is reported as modified. Why
>> not file3? Btw, 'git hash-object file3' reports the same SHA as for the
>> LF-only content in the repository (not so on Linux, as expected).
>>
>> Is this some special handling on Windows (and possibly on Mac OS)? In
>> this case, can someone please point me to the corresponding code part?
>> Thanks for any comments regarding this topic.
>
> Sounds like the core.autocrlf setting (see "git help config"), which I
> believe is set by default on Windows.
>
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-13 8:50 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <4AFD06CD.7090003@gmail.com>
On my slow laptop (P3 600MHz), system-wide bash completions take
too much time to load (> 2s), and a significant fraction of this
time is spent loading git-completion.bash:
$ time bash -c ". ./git-completion.bash" # hot cache, before this patch
real 0m0.509s
user 0m0.310s
sys 0m0.180s
Kirill tracked down that the most time is spent warming up
merge_strategy, all_command & porcelain_command caches.
Since git is not used in each and every interactive xterm, it
seems best to load completion support with cold caches, and then
load each needed thing lazily. This has most of the speed
advantage of pre-generating everything at build time, without the
complication of figuring out at build time what commands will be
available at run time.
The result is that loading completion is significantly faster
now:
$ time bash -c ". ./git-completion.bash" # cold cache, after this patch
real 0m0.171s
user 0m0.060s
sys 0m0.040s
Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
Cc: Shawn O. Pearce <spearce@spearce.org>
Cc: Stephen Boyd <bebarino@gmail.com>
Cc: Sverre Rabbelier <srabbelier@gmail.com>
Cc: Junio C Hamano <junio@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Stephen Boyd wrote:
> Ah ok. I think this proves even more that pregenerating the
> completion is a bad idea. With dynamic population we don't have
> these problems and it only takes 250ms more to load on a P3 700Mhz.
Hmm, 250 ms is a lot.
Strictly speaking, even with the existing completion script, it might
be nice to provide a "hash -r"-like command to bring the caches up to
date. Such a function could be:
git-completion-rehash ()
{
__git_compute_all_commands
__git_compute_merge_strategies
__git_compute_porcelain_commands
}
But that is a separate topic.
contrib/completion/git-completion.bash | 35 +++++++++++++++++--------------
1 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 9e8b607..7088ec7 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -330,10 +330,9 @@ __git_list_merge_strategies ()
}'
}
-__git_merge_strategies ()
+__git_compute_merge_strategies ()
{
- : ${__git_merge_strategylist:=$(__git_list_merge_strategies)}
- echo "$__git_merge_strategylist"
+ : ${__git_merge_strategies=$(__git_list_merge_strategies)}
}
__git_complete_file ()
@@ -468,15 +467,16 @@ __git_complete_remote_or_refspec ()
__git_complete_strategy ()
{
+ __git_compute_merge_strategies
case "${COMP_WORDS[COMP_CWORD-1]}" in
-s|--strategy)
- __gitcomp "$(__git_merge_strategies)"
+ __gitcomp "$__git_merge_strategies"
return 0
esac
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--strategy=*)
- __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
+ __gitcomp "$__git_merge_strategies" "" "${cur##--strategy=}"
return 0
;;
esac
@@ -495,16 +495,16 @@ __git_list_all_commands ()
done
}
-__git_all_commands ()
+__git_compute_all_commands ()
{
- : ${__git_all_commandlist:=$(__git_list_all_commands)}
- echo "$__git_all_commandlist"
+ : ${__git_all_commands=$(__git_list_all_commands)}
}
__git_list_porcelain_commands ()
{
local i IFS=" "$'\n'
- for i in "help" $(__git_all_commands)
+ __git_compute_all_commands
+ for i in "help" $__git_all_commands
do
case $i in
*--*) : helper pattern;;
@@ -586,10 +586,9 @@ __git_list_porcelain_commands ()
done
}
-__git_porcelain_commands ()
+__git_compute_porcelain_commands ()
{
- : ${__git_porcelain_commandlist:=$(__git_list_porcelain_commands)}
- echo "$__git_porcelain_commandlist"
+ : ${__git_porcelain_commands=$(__git_list_porcelain_commands)}
}
__git_aliases ()
@@ -1082,7 +1081,8 @@ _git_help ()
return
;;
esac
- __gitcomp "$(__git_all_commands)
+ __git_compute_all_commands
+ __gitcomp "__git_all_commands
attributes cli core-tutorial cvs-migration
diffcore gitk glossary hooks ignore modules
repository-layout tutorial tutorial-2
@@ -1438,7 +1438,8 @@ _git_config ()
return
;;
pull.twohead|pull.octopus)
- __gitcomp "$(__git_merge_strategies)"
+ __git_compute_merge_strategies
+ __gitcomp "$__git_merge_strategies"
return
;;
color.branch|color.diff|color.interactive|\
@@ -1539,7 +1540,8 @@ _git_config ()
pager.*)
local pfx="${cur%.*}."
cur="${cur#*.}"
- __gitcomp "$(__git_all_commands)" "$pfx" "$cur"
+ __git_compute_all_commands
+ __gitcomp "__git_all_commands" "$pfx" "$cur"
return
;;
remote.*.*)
@@ -2136,7 +2138,8 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
+ *) __git_compute_porcelain_commands
+ __gitcomp "$__git_porcelain_commands $(__git_aliases)" ;;
esac
return
fi
--
1.6.5.2
^ permalink raw reply related
* send an email with logs after push
From: michele @ 2009-11-13 8:46 UTC (permalink / raw)
To: git
Hi guys, I'm using git for a collaborative development and I'm trying to
implement a notification system. I want to automatically send an email
containing the log of each commit after a push. The email should contain
the titles of the commits done between the previous and the last push.
The push action publish the repository on a public_html directory in one
other machine.
Do you have any suggestion to implement this?
Thanks
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-13 9:03 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <20091113085028.GA4804@progeny.tock>
On my slow laptop (P3 600MHz), system-wide bash completions take
too much time to load (> 2s), and a significant fraction of this
time is spent loading git-completion.bash:
$ time bash -c ". ./git-completion.bash" # hot cache, before this patch
real 0m0.509s
user 0m0.310s
sys 0m0.180s
Kirill noticed that most of the time is spent warming up
merge_strategy, all_command & porcelain_command caches.
Since git is not used in each and every interactive xterm, it
seems best to load completion support with cold caches, and then
load each needed thing lazily. This has most of the speed
advantage of pre-generating everything at build time, without the
complication of figuring out at build time what commands will be
available at run time.
The result is that loading completion is significantly faster
now:
$ time bash -c ". ./git-completion.bash" # cold cache, after this patch
real 0m0.171s
user 0m0.060s
sys 0m0.040s
Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
Cc: Shawn O. Pearce <spearce@spearce.org>
Cc: Stephen Boyd <bebarino@gmail.com>
Cc: Sverre Rabbelier <srabbelier@gmail.com>
Cc: Junio C Hamano <junio@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Jonathan Nieder wrote:
> Stephen Boyd wrote:
>> Ah ok. I think this proves even more that pregenerating the
>> completion is a bad idea. With dynamic population we don't have
>> these problems and it only takes 250ms more to load on a P3
>> 700Mhz.
>
> Hmm, 250 ms is a lot.
Here’s the real patch. Sorry about that.
Jonathan
contrib/completion/git-completion.bash | 67 +++++++++++++++----------------
1 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e3ddecc..7088ec7 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -21,13 +21,7 @@
# 2) Added the following line to your .bashrc:
# source ~/.git-completion.sh
#
-# 3) You may want to make sure the git executable is available
-# in your PATH before this script is sourced, as some caching
-# is performed while the script loads. If git isn't found
-# at source time then all lookups will be done on demand,
-# which may be slightly slower.
-#
-# 4) Consider changing your PS1 to also show the current branch:
+# 3) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
#
# The argument to __git_ps1 will be displayed only if you
@@ -324,12 +318,8 @@ __git_remotes ()
done
}
-__git_merge_strategies ()
+__git_list_merge_strategies ()
{
- if [ -n "${__git_merge_strategylist-}" ]; then
- echo "$__git_merge_strategylist"
- return
- fi
git merge -s help 2>&1 |
sed -n -e '/[Aa]vailable strategies are: /,/^$/{
s/\.$//
@@ -339,8 +329,11 @@ __git_merge_strategies ()
p
}'
}
-__git_merge_strategylist=
-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)
+
+__git_compute_merge_strategies ()
+{
+ : ${__git_merge_strategies=$(__git_list_merge_strategies)}
+}
__git_complete_file ()
{
@@ -474,27 +467,24 @@ __git_complete_remote_or_refspec ()
__git_complete_strategy ()
{
+ __git_compute_merge_strategies
case "${COMP_WORDS[COMP_CWORD-1]}" in
-s|--strategy)
- __gitcomp "$(__git_merge_strategies)"
+ __gitcomp "$__git_merge_strategies"
return 0
esac
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--strategy=*)
- __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
+ __gitcomp "$__git_merge_strategies" "" "${cur##--strategy=}"
return 0
;;
esac
return 1
}
-__git_all_commands ()
+__git_list_all_commands ()
{
- if [ -n "${__git_all_commandlist-}" ]; then
- echo "$__git_all_commandlist"
- return
- fi
local i IFS=" "$'\n'
for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
do
@@ -504,17 +494,17 @@ __git_all_commands ()
esac
done
}
-__git_all_commandlist=
-__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
-__git_porcelain_commands ()
+__git_compute_all_commands ()
+{
+ : ${__git_all_commands=$(__git_list_all_commands)}
+}
+
+__git_list_porcelain_commands ()
{
- if [ -n "${__git_porcelain_commandlist-}" ]; then
- echo "$__git_porcelain_commandlist"
- return
- fi
local i IFS=" "$'\n'
- for i in "help" $(__git_all_commands)
+ __git_compute_all_commands
+ for i in "help" $__git_all_commands
do
case $i in
*--*) : helper pattern;;
@@ -595,8 +585,11 @@ __git_porcelain_commands ()
esac
done
}
-__git_porcelain_commandlist=
-__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
+
+__git_compute_porcelain_commands ()
+{
+ : ${__git_porcelain_commands=$(__git_list_porcelain_commands)}
+}
__git_aliases ()
{
@@ -1088,7 +1081,8 @@ _git_help ()
return
;;
esac
- __gitcomp "$(__git_all_commands)
+ __git_compute_all_commands
+ __gitcomp "__git_all_commands
attributes cli core-tutorial cvs-migration
diffcore gitk glossary hooks ignore modules
repository-layout tutorial tutorial-2
@@ -1444,7 +1438,8 @@ _git_config ()
return
;;
pull.twohead|pull.octopus)
- __gitcomp "$(__git_merge_strategies)"
+ __git_compute_merge_strategies
+ __gitcomp "$__git_merge_strategies"
return
;;
color.branch|color.diff|color.interactive|\
@@ -1545,7 +1540,8 @@ _git_config ()
pager.*)
local pfx="${cur%.*}."
cur="${cur#*.}"
- __gitcomp "$(__git_all_commands)" "$pfx" "$cur"
+ __git_compute_all_commands
+ __gitcomp "__git_all_commands" "$pfx" "$cur"
return
;;
remote.*.*)
@@ -2142,7 +2138,8 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
+ *) __git_compute_porcelain_commands
+ __gitcomp "$__git_porcelain_commands $(__git_aliases)" ;;
esac
return
fi
--
1.6.5.2
^ permalink raw reply related
* Re: send an email with logs after push
From: Pascal Obry @ 2009-11-13 8:55 UTC (permalink / raw)
To: michele; +Cc: git
In-Reply-To: <1258101999.17624.1345023113@webmail.messagingengine.com>
Michele,
> Do you have any suggestion to implement this?
I'm doing that. In the post-receive hook I have:
<<
while read oldrev newrev ref; do
trac_post_receive_record_log "$oldrev" "$newrev" "$ref" gtest
send_mail_post_receive "$oldrev" "$newrev" "$ref" gtest \
pascal@obry.net another@here.com
done
>>
the trac_post_receive_record_log is to add log into trac bug tracker.
the send_mail_post_receive is to send a message to the recipients
listed. The 4th parameter is the name of the project.
The send_mail_post_receive function is:
function send_mail_post_receive() {
oldrev=$1
newrev=$2
ref=$3
MODULE="$4"
git log -p $oldrev..$newrev > $log
cat $log | mail -s "[$MODULE] $ref $oldrev..$newrev" $5 $6 $7 $8 $9
rm -fr $root
}
You'll find a set of hook helper routines there:
git clone http://repo.or.cz/r/git-scripts.git
Hope this helps!
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: BUG: git rebase -i -p silently looses commits
From: Johannes Schindelin @ 2009-11-13 9:07 UTC (permalink / raw)
To: Greg Price; +Cc: Constantine Plotnikov, git
In-Reply-To: <1ac2d430911120957gecb6a27k4166016ef8498eab@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3910 bytes --]
Hi Greg,
On Thu, 12 Nov 2009, Greg Price wrote:
> On Wed, Nov 11, 2009 at 12:32 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > That is very interesting!
> >
> > However, for rebase-i-p to have a chance to be accepted, I think a few
> > things are necessary still (this is all from memory, so please take
> > everything with a grain of salt):
>
> Great, this is helpful, and it overlaps with my existing to-do list. I
> have a couple of questions.
>
> > - rework the mark stuff so that 'todo' works properly, and then change
> > the system to use ':<name>' style bookmarks.
>
> This is the biggest change I was going to suggest! Glad we're on the
> same page. To be clear, what I want to do here is
> - add a 'mark' command
> - emit 'mark' commands in the TODO generation for the target of each
> 'goto', and use them.
> Is that also what you had in mind?
Almost. I called it "bookmark" so that the abbreviated command does not
clash with "merge". And there are possible goto targets you have never
been at:
- A - B - C
\ /
D
If C is your HEAD, and you "rebase -i -p B", before cherry-picking D, you
have to "goto A".
So I strongly advise against trying to give all goto targets a name, just
the obvious one: onto (you do not need upstream, as all the commits which
have upstream as parent are supposed to be applied on top of onto anyway).
> > - fix that nasty bug which makes one revision not pass the tests (I
> > forgot which one, but it should be in the TODOs)
>
> Hmm. I see one TODO comment in your patches, and it doesn't sound like
> this. Is there a TODO somewhere else that I'm missing? Alternatively, I
> can always end up just running the tests on all the revisions and find
> out.
It should be in one commit message (something like WIP...).
> > - add proper handling for the case when a patch has been applied in
> > upstream already, but was not correctly identified as that by
> > --cherry-pick (well, this TODO is actually not really related to
> > rebase -i -p, but something I deeply care about)
>
> Hmm. I'll have to think about what the behavior could be here.
At the moment, it gives you the status (which is multiple pages long here,
due to untracked files that I am unwilling to move elsewhere) and then
"nothing to commit". You do not even see which commit was to be applied.
My plan was to detect that condition in the error case and _not_ output
what the cherry-pick printed, but a much more helpful message along the
lines
It appears "Bla bli blu" was already applied
For the exact message, I am sure all kinds of painters will want to help
you.
> For context, I think the issue you're referring to is that sometimes
> the patch-id changed, so that --cherry-pick doesn't identify the
> patch;
Correct.
> and then some later upstream patch has touched the same code again, so
> that there's a conflict when we try to apply the older patch.
No, that is not what I mean. I mean when more than one context line
changes. Then patch-ids will differ, but a 3-way merge will still succeed
in finding that there was actually no change.
> > Unfortunately, I am getting more and more deprived of Git time budget
> > these days, so that I cannot seem to find a few hours to at least
> > restart my efforts.
>
> Understood. I may have some time to work on this soon, we'll see. I
> think the priorities will be to
> - add "mark" as you say
> - add the "pause" command, to make it possible to amend a merge
> - write tests
> - fix a couple of bugs, track down the one you mentioned
> - write documentation
>
> At that point, and with the reordering you suggested, I think it will
> be ready to submit for inclusion.
>
> Further comments, and bug reports from anyone else using the
> development version, are welcome.
Thanks,
Dscho
P.S.: I am mostly off-line until Monday.
^ permalink raw reply
* Re: git status internals and line endings
From: Erik Faye-Lund @ 2009-11-13 9:04 UTC (permalink / raw)
To: Marc Strapetz; +Cc: Jeff King, git
In-Reply-To: <4AFD1414.6030907@syntevo.com>
On Fri, Nov 13, 2009 at 9:08 AM, Marc Strapetz
<marc.strapetz@syntevo.com> wrote:
>> Sounds like the core.autocrlf setting (see "git help config"), which I
>> believe is set by default on Windows.
>
> I have checked both $GIT_DIR/config and ~/.gitconfig and autocrlf has
> not been set. I have then set autocrlf = false for the Windows
> repository and still the file didn't show up as modified. On Linux, I've
> added autocrlf = true (resp. autocrlf = input) for the repository and
> still the file shows up as modified. Not that I don't like this
> behavior, but I don't understand it :) Windows Git version is 1.6.5.1,
> Linux version is 1.6.3.3.
>
In order to make changes to core.autocrlf effective, you need to
delete .git/index and perform a hard reset:
$ rm .git/index
$ git reset --hard
Did you do this before checking if the files were modified?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Git in next is broken
From: Julian Phillips @ 2009-11-13 9:14 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: René Scharfe, git
In-Reply-To: <alpine.LFD.2.00.0911122345450.16711@xanadu.home>
On Thu, 12 Nov 2009, Nicolas Pitre wrote:
> On Thu, 12 Nov 2009, Julian Phillips wrote:
>
>> On Thu, 12 Nov 2009, Ren? Scharfe wrote:
>>
>>> Nicolas Pitre schrieb:
>>>> Simply issuing a "git fetch" in my copy of git.git makes glibc complain
>>>> with this:
>>>>
>>>> *** glibc detected *** git: corrupted double-linked list:
>>>> 0x0000000000974180 ***
>>> Can't reproduce because I don't know how to create duplicate refs, but does
>>> the following help?
>
> Nope.
>
>>> remote.c | 2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/remote.c b/remote.c
>>> index 4f9f0cc..10cc985 100644
>>> --- a/remote.c
>>> +++ b/remote.c
>>> @@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
>>> prev->next = ref_map->next;
>>> free(ref_map->peer_ref);
>>> free(ref_map);
>>> + ref_map = next;
>>
>> You don't need this line (this is taken care of in the for(...)).
>>
>>> + continue;
>>
>> Ack. This one however, you do need. Good catch.
>
> Without the "ref_map = next" there is no change: glibc still complains
> about corruption and abort the execution. With the "ref_map = next"
> then git simply segfaults.
>
> I simply have zero time to investigate the issue myself now
> unfortunately.
I was half right about "ref_map = next", I had forgotten about setting
prev in the for(...). For me, the following fixes it on MacOS (I don't
have time to test on Linux right now):
diff --git a/remote.c b/remote.c
index 4f9f0cc..6195a58 100644
--- a/remote.c
+++ b/remote.c
@@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
prev->next = ref_map->next;
free(ref_map->peer_ref);
free(ref_map);
+ ref_map = prev; // Keep the same prev.
+ continue;
}
item = string_list_insert(ref_map->peer_ref->name, &refs);
--
Julian
---
C'est magnifique, mais ce n'est pas l'Informatique.
-- Bosquet [on seeing the IBM 4341]
^ permalink raw reply related
* Re: git status internals and line endings
From: Peter Krefting @ 2009-11-13 9:40 UTC (permalink / raw)
To: Marc Strapetz; +Cc: Jeff King, Git Mailing List
In-Reply-To: <4AFD1414.6030907@syntevo.com>
Marc Strapetz:
>> Sounds like the core.autocrlf setting (see "git help config"), which I
>> believe is set by default on Windows.
> I have checked both $GIT_DIR/config and ~/.gitconfig and autocrlf has not
> been set.
It is usually set by default by the installer. Look at
%INSTALLDIR%\etc\gitconfig, it should contain
[core]
autoCRLF = true
among other things.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* git am and CRLF files
From: Stefan Naewe @ 2009-11-13 9:44 UTC (permalink / raw)
To: git
Hi there.
I have:
$ git version
git version 1.6.5.1.1367.gcd48
$ git config --get core.autocrlf
false
A repository with some UNIX (LF) and some Windows (CRLF) files.
(and no: I will not change the files. My editors handle CRLF and LF correctly)
My problem:
'git am' can't handle changes in CRLF files because the patch
gets converted (by git mailsplit) to contain only LF.
Which is wrong IMHO.
git-am on my msysgit version looks like this (lines: 214++)
<---------->
split_patches () {
case "$patch_format" in
mbox)
case "$rebasing" in
'')
keep_cr= ;;
?*)
keep_cr=--keep-cr ;;
esac
git mailsplit -d"$prec" -o"$dotest" -b $keep_cr -- "$@" > "$dotest/last" ||
clean_abort
;;
<---------->
The '--keep-cr' flags is passed to git mailsplit when git am is in 'rebasing' mode.
By looking through git-am I found that I can pass "--rebasing" to git am to get my
patch applied correctly.
But why is git am behaving that way ?
Puzzled,
Stefan
--
----------------------------------------------------------------
/dev/random says: I'm dangerous when I know what I'm doing.
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-13 10:29 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <20091113090343.GA5355@progeny.tock>
Jonathan Nieder wrote:
> @@ -1545,7 +1540,8 @@ _git_config ()
> pager.*)
> local pfx="${cur%.*}."
> cur="${cur#*.}"
> - __gitcomp "$(__git_all_commands)" "$pfx" "$cur"
> + __git_compute_all_commands
> + __gitcomp "__git_all_commands" "$pfx" "$cur"
> return
> ;;
> remote.*.*)
s/__git_all_commands/\$__git_all_commands/
Yikes. Next patch I’ll let sit for a day.
Good night,
Jonathan
^ permalink raw reply
* Warning while cloning remote repository
From: Shameem Ahamed @ 2009-11-13 10:20 UTC (permalink / raw)
To: git
Hi,
I ran in to a warning message while cloning a remote repository.
The message is
warning: remote HEAD refers to nonexistent ref, unable to checkout.
After the cloning i couldn't see any remote files. The .git folder is created successfully.
Regards,
Shameem
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox