* Re: git rebase --interactive problems
From: Jeff Epler @ 2009-09-07 13:03 UTC (permalink / raw)
To: Dave Rodgman; +Cc: git
In-Reply-To: <1252326716.7497.1333578429@webmail.messagingengine.com>
It looks like something is going wrong with the 'grep -c' in
mark_action_done () {
sed -e 1q < "$TODO" >> "$DONE"
sed -e 1d < "$TODO" >> "$TODO".new
mv -f "$TODO".new "$TODO"
count=$(grep -c '^[^#]' < "$DONE")
total=$(($count+$(grep -c '^[^#]' < "$TODO")))
if test "$last_count" != "$count"
then
last_count=$count
printf "Rebasing (%d/%d)\r" $count $total
test -z "$VERBOSE" || echo
fi
}
are you using an unusual platform or have an unusual /bin/grep or
/bin/sh?
Jeff
^ permalink raw reply
* [PATCH] gitweb: Add 'show-sizes' feature to show blob sizes in tree view
From: Jakub Narebski @ 2009-09-07 12:40 UTC (permalink / raw)
To: git
Add support for 'show-sizes' feature to show (in separate column,
between mode and filename) the size of blobs (files) in the 'tree'
view. It passes '-l' option to "git ls-tree" invocation.
For the 'tree' and 'commit' (submodule) entries, '-' is shown in place
of size; for generated '..' "up directory" entry nothing is shown.
The 'show-sizes' feature is enabled by default.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I am sorry if this patch was sent twice to git mailing list
I don't quite like 'show-sizes' as a name for this feature.
Does anyone has any better ideas?
Not tested extensively (just that it works, and looks correct),
in particular I didn't test that having 'gitweb.showsizes' as
config variable name while 'show-sizes' as feature name works
as expected.
Previous version of this idea was presented in
http://thread.gmane.org/gmane.comp.version-control.git/54335/focus=54334
It required to pass '-l' to 'tree' action via 'opt' (extra options)
parameter. This one uses features mechanism.
This patch might have @extra_options passed unnecessary...
gitweb/gitweb.css | 6 +++++
gitweb/gitweb.perl | 69 +++++++++++++++++++++++++++++++++++++++++-----------
2 files changed, 60 insertions(+), 15 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 8f68fe3..d60bfc1 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -341,6 +341,12 @@ td.mode {
font-family: monospace;
}
+/* format of (optional) objects size in 'tree' view */
+td.size {
+ font-family: monospace;
+ text-align: right;
+}
+
/* styling of diffs (patchsets): commitdiff and blobdiff views */
div.diff.header,
div.diff.extended_header {
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 24b2193..7b1c60e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -297,6 +297,19 @@ our %feature = (
'override' => 0,
'default' => [1]},
+ # Enable showing size of blobs in a 'tree' view, in a separate
+ # column, similar to what 'ls -l' does. This cost a bit of IO.
+
+ # To disable system wide have in $GITWEB_CONFIG
+ # $feature{'show-sizes'}{'default'} = [0];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'show-sizes'}{'override'} = 1;
+ # and in project config gitweb.showsizes = 0|1;
+ 'show-sizes' => {
+ 'sub' => sub { feature_bool('showsizes', @_) },
+ 'override' => 0,
+ 'default' => [1]},
+
# Make gitweb use an alternative format of the URLs which can be
# more readable and natural-looking: project name is embedded
# directly in the path and the query string contains other
@@ -2764,16 +2777,31 @@ sub parse_ls_tree_line {
my %opts = @_;
my %res;
- #'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
- $line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t(.+)$/s;
+ if ($opts{'-l'}) {
+ #'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa 16717 panic.c'
+ $line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40}) +(-|[0-9]+)\t(.+)$/s;
- $res{'mode'} = $1;
- $res{'type'} = $2;
- $res{'hash'} = $3;
- if ($opts{'-z'}) {
- $res{'name'} = $4;
+ $res{'mode'} = $1;
+ $res{'type'} = $2;
+ $res{'hash'} = $3;
+ $res{'size'} = $4;
+ if ($opts{'-z'}) {
+ $res{'name'} = $5;
+ } else {
+ $res{'name'} = unquote($5);
+ }
} else {
- $res{'name'} = unquote($4);
+ #'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
+ $line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t(.+)$/s;
+
+ $res{'mode'} = $1;
+ $res{'type'} = $2;
+ $res{'hash'} = $3;
+ if ($opts{'-z'}) {
+ $res{'name'} = $4;
+ } else {
+ $res{'name'} = unquote($4);
+ }
}
return wantarray ? %res : \%res;
@@ -3564,6 +3592,9 @@ sub git_print_tree_entry {
# and link is the action links of the entry.
print "<td class=\"mode\">" . mode_str($t->{'mode'}) . "</td>\n";
+ if (exists $t->{'size'}) {
+ print "<td class=\"size\">$t->{'size'}</td>\n";
+ }
if ($t->{'type'} eq "blob") {
print "<td class=\"list\">" .
$cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
@@ -3609,12 +3640,14 @@ sub git_print_tree_entry {
} elsif ($t->{'type'} eq "tree") {
print "<td class=\"list\">";
print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
+ file_name=>"$basedir$t->{'name'}",
+ %base_key)},
esc_path($t->{'name'}));
print "</td>\n";
print "<td class=\"link\">";
print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
+ file_name=>"$basedir$t->{'name'}",
+ %base_key)},
"tree");
if (defined $hash_base) {
print " | " .
@@ -5088,10 +5121,14 @@ sub git_tree {
}
die_error(404, "No such tree") unless defined($hash);
+ my $show_sizes = gitweb_check_feature('show-sizes');
+ my $have_blame = gitweb_check_feature('blame');
+
my @entries = ();
{
local $/ = "\0";
- open my $fd, "-|", git_cmd(), "ls-tree", '-z', $hash
+ open my $fd, "-|", git_cmd(), "ls-tree", '-z',
+ ($show_sizes ? '-l' : ()), @extra_options, $hash
or die_error(500, "Open git-ls-tree failed");
@entries = map { chomp; $_ } <$fd>;
close $fd
@@ -5102,7 +5139,6 @@ sub git_tree {
my $ref = format_ref_marker($refs, $hash_base);
git_header_html();
my $basedir = '';
- my $have_blame = gitweb_check_feature('blame');
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
my @views_nav = ();
if (defined $file_name) {
@@ -5118,7 +5154,8 @@ sub git_tree {
# FIXME: Should be available when we have no hash base as well.
push @views_nav, $snapshot_links;
}
- git_print_page_nav('tree','', $hash_base, undef, undef, join(' | ', @views_nav));
+ git_print_page_nav('tree','', $hash_base, undef, undef,
+ join(' | ', @views_nav));
git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash_base);
} else {
undef $hash_base;
@@ -5151,8 +5188,10 @@ sub git_tree {
undef $up unless $up;
# based on git_print_tree_entry
print '<td class="mode">' . mode_str('040000') . "</td>\n";
+ print '<td class="size"> </td>'."\n" if $show_sizes;
print '<td class="list">';
- print $cgi->a({-href => href(action=>"tree", hash_base=>$hash_base,
+ print $cgi->a({-href => href(action=>"tree",
+ hash_base=>$hash_base,
file_name=>$up)},
"..");
print "</td>\n";
@@ -5161,7 +5200,7 @@ sub git_tree {
print "</tr>\n";
}
foreach my $line (@entries) {
- my %t = parse_ls_tree_line($line, -z => 1);
+ my %t = parse_ls_tree_line($line, -z => 1, -l => $show_sizes);
if ($alternate) {
print "<tr class=\"dark\">\n";
^ permalink raw reply related
* [PATCH resend] git-pull: fix fetch-options.txt to not document --quiet and --verbose twice in git-pull.txt
From: Emmanuel Trillaud @ 2009-09-07 12:34 UTC (permalink / raw)
To: Git Mailing List
Hello all,
In git-pull(1) we can read :
OPTIONS
-q, --quiet
Operate quietly.
-v, --verbose
Be verbose.
...
-q, --quiet
Pass --quiet to git-fetch-pack and silence any other
internally used git
commands.
-v, --verbose
Be verbose.
The first part is included by merge-option.txt and the second by
fetch-options.txt.
I choose to "suppress" the fetch-options part because IMHO we don't
need that level
of precision. But if you prefer, I can provide a patch to "ifndef" the
merge-options.txt part.
Best regard
git-pull.txt includes fetch-options.txt and merge-options.txt which both
document the --quiet and --verbose parameters. So we supress the
--quiet and --verbose paragraphs if fetch-options.txt is included by
git-pull.txt
Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
---
Documentation/fetch-options.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index ea3b1bc..5eb2b0e 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,3 +1,4 @@
+ifndef::git-pull[]
-q::
--quiet::
Pass --quiet to git-fetch-pack and silence any other internally
@@ -6,6 +7,7 @@
-v::
--verbose::
Be verbose.
+endif::git-pull[]
-a::
--append::
--
1.6.4.2.253.g0b1fac
^ permalink raw reply related
* git rebase --interactive problems
From: Dave Rodgman @ 2009-09-07 12:31 UTC (permalink / raw)
To: git
When I try to do even the simplest rebase --interactive, I get a cryptic
error message:
$ git rebase -i HEAD~2
<do nothing in the editor that appears, just save>
I then get:
/usr/lib/git-core/git-rebase--interactive: 1: arithmetic expression:
expecting primary: "-c ^[^#]
2+-c ^[^#]
0"
and all I can do is git rebase --abort
Am I doing something wrong, or is this a bug? I am using git 1.6.4.2
thanks
Dave
^ permalink raw reply
* Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Erik Faye-Lund @ 2009-09-07 12:26 UTC (permalink / raw)
To: Frank Li
Cc: Thiago Farina, Marius Storm-Olsen, Reece Dunn,
Johannes.Schindelin, msysgit, git
In-Reply-To: <1976ea660908250732q1e1fc153g663f3a9c13f1c902@mail.gmail.com>
On Tue, Aug 25, 2009 at 4:32 PM, Frank Li<lznuaa@gmail.com> wrote:
> I update http://repo.or.cz/w/gitbuild.git.
> Add create_command.bat to create common-cmds.h.
I just gave this script a try, but if I simply click the .bat-file, I
get the following crash in sh.exe: "Unhandled exception at 0x77ba8e7c
in sh.exe: 0xC0000005: Access violation writing location 0x00000014."
Here's the output I get on the console:
--->8---
C:\Users\Erik\src\git-msvc\gitbuild>setlocal
C:\Users\Erik\src\git-msvc\gitbuild>set tools=C:\Users\Erik\src\git-msvc\gitbuil
d\tools
C:\Users\Erik\src\git-msvc\gitbuild>echo C:\Users\Erik\src\git-msvc\gitbuild\too
ls
C:\Users\Erik\src\git-msvc\gitbuild\tools
C:\Users\Erik\src\git-msvc\gitbuild>set path=C:\Users\Erik\src\git-msvc\gitbuild
\tools
C:\Users\Erik\src\git-msvc\gitbuild>cd ext\git
C:\Users\Erik\src\git-msvc\gitbuild\ext\git>sh generate-cmdlist.sh 1>common-cmd
s.h
abnormal program termination
--->8---
Since the path is set to only point to the tools, my guess is that
other msys installations (I've got two) shouldn't affect this, no?
I'm running Vista 64bit.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Use case I don't know how to address
From: Alan Chandler @ 2009-09-07 12:08 UTC (permalink / raw)
To: git
In-Reply-To: <4AA4F632.3070206@chandlerfamily.org.uk>
Alan Chandler wrote:
> Alan Chandler wrote:
>> Junio C Hamano wrote:
>>> Alan Chandler <alan@chandlerfamily.org.uk> writes:
>>>
>>>> 2' - 2a - 3' - 4' ----------------- 6' SITE
>>>> / / / /
>>>> 1 - 2 ------ 3 - 4 ------------6'''- 6a TEST
>>>> \ /
>>>> 5 ------ 6 MASTER
>>>> \ \
>>>> 5''- 5a- 6'' DEMO
>>>>
>>>>
>>>> What will happen is the changes made in 4->5 will get applied to the
>>>> (now) Test branch as part of the 6->6'' merge, and I will be left
>>>> having to add a new commit, 6a, to undo them all again. Given this is
>>>> likely to be quite a substantial change I want to try and avoid it if
>>>> possible.
>>>
>>> I presume 6'''-6a has the revert of 4-5? If so, the next merge should
>>> work just fine.
>>
>>
>> I think you missed the issue - Yes 6'''-6a is the revert, but the
>> problem is this could be large and complicated, and I wanted to find
>> an automated way rather than manual
>>
>> Sort of like doing a diff of 4-5 and somehow applying it backwards.
>>
>>
>
> I just discovered that git-apply has the -R flag. Is that what I am
> looking for?
>
2' - 2a - 3' - 4' ------------ 6' SITE
/ / / /
1 - 2 ------ 3 - 4 --5'''--5b---6''' TEST
\ / /
5 ------ 6 MASTER
\ \
5''- 5a- 6'' DEMO
Just to be clear - if I do a diff of 4->5 and then immediately merge it
back to 4 as 5'' (which fast forwards 4) and then 5b is the diff of 4-5
applied with git apply -R.
Is that what the -R flag does on git apply?
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: Use case I don't know how to address
From: Alan Chandler @ 2009-09-07 12:01 UTC (permalink / raw)
Cc: git
In-Reply-To: <4AA3AEA1.7030107@chandlerfamily.org.uk>
Alan Chandler wrote:
> Junio C Hamano wrote:
>> Alan Chandler <alan@chandlerfamily.org.uk> writes:
>>
>>> 2' - 2a - 3' - 4' ----------------- 6' SITE
>>> / / / /
>>> 1 - 2 ------ 3 - 4 ------------6'''- 6a TEST
>>> \ /
>>> 5 ------ 6 MASTER
>>> \ \
>>> 5''- 5a- 6'' DEMO
>>>
>>>
>>> What will happen is the changes made in 4->5 will get applied to the
>>> (now) Test branch as part of the 6->6'' merge, and I will be left
>>> having to add a new commit, 6a, to undo them all again. Given this is
>>> likely to be quite a substantial change I want to try and avoid it if
>>> possible.
>>
>> I presume 6'''-6a has the revert of 4-5? If so, the next merge should
>> work just fine.
>
>
> I think you missed the issue - Yes 6'''-6a is the revert, but the
> problem is this could be large and complicated, and I wanted to find an
> automated way rather than manual
>
> Sort of like doing a diff of 4-5 and somehow applying it backwards.
>
>
I just discovered that git-apply has the -R flag. Is that what I am
looking for?
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* [PATCH/RFC] gitweb: Add 'show-sizes' feature to show blob sizes in tree view
From: Jakub Narebski @ 2009-09-07 12:00 UTC (permalink / raw)
To: git, git; +Cc: Jakub Narebski
Add support for 'show-sizes' feature to show (in separate column,
between mode and filename) the size of blobs (files) in the 'tree'
view. It passes '-l' option to "git ls-tree" invocation.
For the 'tree' and 'commit' (submodule) entries, '-' is shown in place
of size; for generated '..' "up directory" entry nothing is shown.
The 'show-sizes' feature is enabled by default.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I don't quite like 'show-sizes' as a name for this feature.
Does anyone has any better ideas?
Not tested extensively (just that it works, and looks correct),
in particular I didn't test that having 'gitweb.showsizes' as
config variable name while 'show-sizes' as feature name works
as expected.
Previous version of this idea was presented in
http://thread.gmane.org/gmane.comp.version-control.git/54335/focus=54334
It required to pass '-l' to 'tree' action via 'opt' (extra options)
parameter. This one uses features mechanism.
This patch might have @extra_options passed unnecessary...
gitweb/gitweb.css | 6 +++++
gitweb/gitweb.perl | 69 +++++++++++++++++++++++++++++++++++++++++-----------
2 files changed, 60 insertions(+), 15 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 8f68fe3..d60bfc1 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -341,6 +341,12 @@ td.mode {
font-family: monospace;
}
+/* format of (optional) objects size in 'tree' view */
+td.size {
+ font-family: monospace;
+ text-align: right;
+}
+
/* styling of diffs (patchsets): commitdiff and blobdiff views */
div.diff.header,
div.diff.extended_header {
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 24b2193..7b1c60e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -297,6 +297,19 @@ our %feature = (
'override' => 0,
'default' => [1]},
+ # Enable showing size of blobs in a 'tree' view, in a separate
+ # column, similar to what 'ls -l' does. This cost a bit of IO.
+
+ # To disable system wide have in $GITWEB_CONFIG
+ # $feature{'show-sizes'}{'default'} = [0];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'show-sizes'}{'override'} = 1;
+ # and in project config gitweb.showsizes = 0|1;
+ 'show-sizes' => {
+ 'sub' => sub { feature_bool('showsizes', @_) },
+ 'override' => 0,
+ 'default' => [1]},
+
# Make gitweb use an alternative format of the URLs which can be
# more readable and natural-looking: project name is embedded
# directly in the path and the query string contains other
@@ -2764,16 +2777,31 @@ sub parse_ls_tree_line {
my %opts = @_;
my %res;
- #'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
- $line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t(.+)$/s;
+ if ($opts{'-l'}) {
+ #'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa 16717 panic.c'
+ $line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40}) +(-|[0-9]+)\t(.+)$/s;
- $res{'mode'} = $1;
- $res{'type'} = $2;
- $res{'hash'} = $3;
- if ($opts{'-z'}) {
- $res{'name'} = $4;
+ $res{'mode'} = $1;
+ $res{'type'} = $2;
+ $res{'hash'} = $3;
+ $res{'size'} = $4;
+ if ($opts{'-z'}) {
+ $res{'name'} = $5;
+ } else {
+ $res{'name'} = unquote($5);
+ }
} else {
- $res{'name'} = unquote($4);
+ #'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
+ $line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t(.+)$/s;
+
+ $res{'mode'} = $1;
+ $res{'type'} = $2;
+ $res{'hash'} = $3;
+ if ($opts{'-z'}) {
+ $res{'name'} = $4;
+ } else {
+ $res{'name'} = unquote($4);
+ }
}
return wantarray ? %res : \%res;
@@ -3564,6 +3592,9 @@ sub git_print_tree_entry {
# and link is the action links of the entry.
print "<td class=\"mode\">" . mode_str($t->{'mode'}) . "</td>\n";
+ if (exists $t->{'size'}) {
+ print "<td class=\"size\">$t->{'size'}</td>\n";
+ }
if ($t->{'type'} eq "blob") {
print "<td class=\"list\">" .
$cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
@@ -3609,12 +3640,14 @@ sub git_print_tree_entry {
} elsif ($t->{'type'} eq "tree") {
print "<td class=\"list\">";
print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
+ file_name=>"$basedir$t->{'name'}",
+ %base_key)},
esc_path($t->{'name'}));
print "</td>\n";
print "<td class=\"link\">";
print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
+ file_name=>"$basedir$t->{'name'}",
+ %base_key)},
"tree");
if (defined $hash_base) {
print " | " .
@@ -5088,10 +5121,14 @@ sub git_tree {
}
die_error(404, "No such tree") unless defined($hash);
+ my $show_sizes = gitweb_check_feature('show-sizes');
+ my $have_blame = gitweb_check_feature('blame');
+
my @entries = ();
{
local $/ = "\0";
- open my $fd, "-|", git_cmd(), "ls-tree", '-z', $hash
+ open my $fd, "-|", git_cmd(), "ls-tree", '-z',
+ ($show_sizes ? '-l' : ()), @extra_options, $hash
or die_error(500, "Open git-ls-tree failed");
@entries = map { chomp; $_ } <$fd>;
close $fd
@@ -5102,7 +5139,6 @@ sub git_tree {
my $ref = format_ref_marker($refs, $hash_base);
git_header_html();
my $basedir = '';
- my $have_blame = gitweb_check_feature('blame');
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
my @views_nav = ();
if (defined $file_name) {
@@ -5118,7 +5154,8 @@ sub git_tree {
# FIXME: Should be available when we have no hash base as well.
push @views_nav, $snapshot_links;
}
- git_print_page_nav('tree','', $hash_base, undef, undef, join(' | ', @views_nav));
+ git_print_page_nav('tree','', $hash_base, undef, undef,
+ join(' | ', @views_nav));
git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash_base);
} else {
undef $hash_base;
@@ -5151,8 +5188,10 @@ sub git_tree {
undef $up unless $up;
# based on git_print_tree_entry
print '<td class="mode">' . mode_str('040000') . "</td>\n";
+ print '<td class="size"> </td>'."\n" if $show_sizes;
print '<td class="list">';
- print $cgi->a({-href => href(action=>"tree", hash_base=>$hash_base,
+ print $cgi->a({-href => href(action=>"tree",
+ hash_base=>$hash_base,
file_name=>$up)},
"..");
print "</td>\n";
@@ -5161,7 +5200,7 @@ sub git_tree {
print "</tr>\n";
}
foreach my $line (@entries) {
- my %t = parse_ls_tree_line($line, -z => 1);
+ my %t = parse_ls_tree_line($line, -z => 1, -l => $show_sizes);
if ($alternate) {
print "<tr class=\"dark\">\n";
^ permalink raw reply related
* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Matthieu Moy @ 2009-09-07 11:20 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, Junio C Hamano, Teemu Likonen, Git
In-Reply-To: <20090907085405.GA17968@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I'm not sure it solves the problem. The point of "message.all" was to
> easily say "I'm an expert, so turn off useless advice". But now I would
> have to manually re-enable any messages that I _do_ want to see. And of
> course I don't see them to know that I want them, so I have to read
> through the config documentation and decide on each one.
Well, if it was _that_ important, I'd go for your suggestion of a
message hierarchy message.advice.foo, message.info.bar and so, with
the possibility of enabling/disabling a subhierarchy with a config
option. Now, I really get the feeling that this is overkill...
> So I think "be verbose, but let the user quiet us" is probably
> better than "be quiet, but let the user make us louder", because it is
> easier to discover verbose things. Which implies to me that
> "message.all", if it exists at all, should be limited in scope to just
> advice.
Yup, you convinced me for the last implication.
Otherwise, one setting "message.all = false" would never even notice
that another very cool informative message was added to Git in its
latest version.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Do not scramble password read from .cvspass
From: Dirk Hörner @ 2009-09-07 10:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, pascal
In-Reply-To: <7vvdjyn0j3.fsf@alter.siamese.dyndns.org>
Hi Junio,
On Fri, Sep 4, 2009 at 6:21 PM, Junio C Hamano<gitster@pobox.com> wrote:
> Dirk, does the patch look Ok to you?
The patch looks fine :-)
Ciao,
Dirk
>
>> git-cvsimport.perl | 7 ++++---
>> 1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/git-cvsimport.perl b/git-cvsimport.perl
>> index 593832d..c5cdcae 100755
>> --- a/git-cvsimport.perl
>> +++ b/git-cvsimport.perl
>> @@ -238,7 +238,10 @@ sub conn {
>> }
>> my $rr = ":pserver:$user\@$serv:$port$repo";
>>
>> - unless ($pass) {
>> + if ($pass) {
>> + $pass = $self->_scramble($pass);
>> + } else
>> + {
>> open(H,$ENV{'HOME'}."/.cvspass") and do {
>> #
>> :pserver:cvs@mea.tmt.tele.fi:/cvsroot/zmailer Ah<Z
>> while (<H>) {
>> @@ -253,8 +256,6 @@ sub conn {
>> };
>> }
>>
>> - $pass = $self->_scramble($pass);
>> -
>> my ($s, $rep);
>> if ($proxyhost) {
>>
>> --
>> 1.6.4.2.253.g0b1fac
>
^ permalink raw reply
* Re: tracking branch for a rebase
From: Michael J Gruber @ 2009-09-07 9:53 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Björn Steinbrink, Pete Wyckoff,
git
In-Reply-To: <alpine.DEB.1.00.0909071126040.8306@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 07.09.2009 11:29:
> Hi,
>
> On Mon, 7 Sep 2009, Jeff King wrote:
>
>> On Sun, Sep 06, 2009 at 10:05:21PM -0700, Junio C Hamano wrote:
>>
>>> ref@{number} -- nth reflog entry
>>> ref@{time} -- ref back then
>>> @{-number} -- nth branch switching
>>>
>>> So perhaps ref@{upstream}, or any string that is not a number and cannot
>>> be time, can trigger the magic operation on the ref with ref@{magic}
>>> syntax?
>>
>> I think using @{} is a reasonable extension format.
>
> Sorry to enter this thread that late, but I did not realize that it
> touches my %<branch> work.
>
> Your proposal leads to something like "master@{upstream}@{2.days.ago}",
> which looks ugly. And it is much more to type.
>
> I still think that it is not too-much asked for to require the
> "refs/heads/" prefix if somebody starts her branch names with "%".
>
> Or did I miss something (as I do not have time to read long mails these
> days, I tend to read only the short, to-the-point ones; I allowed myself
> to only skim over the rest of your mail)?
Solution needs to be:
- practical (short, clear)
- not too brutal (on existing users of legal "exotic" refnames)
- extensible (for later uses)
Michael
152 chars for Dscho :)
^ permalink raw reply
* Re: how to skip branches on git svn clone/fetch when there are errors
From: Daniele Segato @ 2009-09-07 9:30 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <9accb4400908310126v15b08c7fr425c9daff26012f3@mail.gmail.com>
On Mon, Aug 31, 2009 at 10:26 AM, Daniele
Segato<daniele.bilug@gmail.com> wrote:>
> git init
> git svn init svn://svn.mydomain.com/path/to/repo -T HEAD -b BRANCHES -t TAGS
> $ git svn fetch
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/SVN/Core.pm line 584.
> Authorization failed: at /usr/bin/git-svn line 1415
>
more info on the error (enabled the confess instead of croak to the
Core.pm library)
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/SVN/Core.pm line 585.
Authorization failed: at /usr/lib/perl5/SVN/Core.pm line 654
SVN::Error::confess_on_error('_p_svn_error_t=SCALAR(0x9492a50)')
called at /usr/lib/perl5/SVN/Ra.pm line 492
SVN::Ra::AUTOLOAD('Git::SVN::Ra=HASH(0x945dae8)',
'alfresco-enterprise-mirror/alfresco/BRANCHES/V2.1-A/root', 7738,
'SVN::Pool=REF(0x9492bc0)') called at /usr/bin/git-svn line 3760
Git::SVN::Ra::check_path('Git::SVN::Ra=HASH(0x945dae8)',
'alfresco-enterprise-mirror/alfresco/BRANCHES/V2.1-A/root', 7738)
called at /usr/bin/git-svn line 4045
Git::SVN::Ra::get_dir_check('Git::SVN::Ra=HASH(0x945dae8)',
'HASH(0x92131e0)', 'HASH(0x9388050)', 7738) called at /usr/bin/git-svn
line 4062
Git::SVN::Ra::match_globs('Git::SVN::Ra=HASH(0x945dae8)',
'HASH(0x92131e0)', 'HASH(0x9463c00)', 'ARRAY(0x90bbc00)', 7738) called
at /usr/bin/git-svn line 3985
Git::SVN::Ra::gs_fetch_loop_common('Git::SVN::Ra=HASH(0x945dae8)',
7737, 16113, 'ARRAY(0x90bbbe0)', 'ARRAY(0x90bbc00)') called at
/usr/bin/git-svn line 1415
Git::SVN::fetch_all('svn', 'HASH(0x9464250)') called at
/usr/bin/git-svn line 372
main::cmd_fetch() called at /usr/bin/git-svn line 253
eval {...} called at /usr/bin/git-svn line 251
I'll keep looking at it to see if I can figure out a way to "skip" the
error myself and, eventually, provide a patch
Bye,
Daniele
^ permalink raw reply
* Re: tracking branch for a rebase
From: Johannes Schindelin @ 2009-09-07 9:29 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <20090907084324.GB17997@coredump.intra.peff.net>
Hi,
On Mon, 7 Sep 2009, Jeff King wrote:
> On Sun, Sep 06, 2009 at 10:05:21PM -0700, Junio C Hamano wrote:
>
> > ref@{number} -- nth reflog entry
> > ref@{time} -- ref back then
> > @{-number} -- nth branch switching
> >
> > So perhaps ref@{upstream}, or any string that is not a number and cannot
> > be time, can trigger the magic operation on the ref with ref@{magic}
> > syntax?
>
> I think using @{} is a reasonable extension format.
Sorry to enter this thread that late, but I did not realize that it
touches my %<branch> work.
Your proposal leads to something like "master@{upstream}@{2.days.ago}",
which looks ugly. And it is much more to type.
I still think that it is not too-much asked for to require the
"refs/heads/" prefix if somebody starts her branch names with "%".
Or did I miss something (as I do not have time to read long mails these
days, I tend to read only the short, to-the-point ones; I allowed myself
to only skim over the rest of your mail)?
Ciao,
Dscho
^ permalink raw reply
* Re: Issue 323 in msysgit: Can't clone over http
From: Tay Ray Chuan @ 2009-09-07 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit, Tom Preston-Werner
In-Reply-To: <7vocpn44dg.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, Sep 7, 2009 at 3:10 PM, Junio C Hamano<gitster@pobox.com> wrote:
> We couldn't perform the check, and then what happens? We continue as if
> everything is peachy, assuming that the *.idx file we thought we were
> going to get describe what objects are in the corresponding pack, and barf
> when we try to read the *.idx file that we failed to download even though
> the server said we should be able to get it?
We didn't check for the *.idx, only the corresponding *.pack file.
About barfing on a failed *.idx file transfer: in 48188c2 and later, we
still do have ample checks here and there in the HTTP api. http_get_file()
returns a HTTP_ERROR if we fail to get a file (a *.idx file here).
The issue is that the check on the file (a HEAD request) fails, but not
its actual transfer (a GET request). There's no compromise on error
handling; we can live with a bad response to HEAD requests, but we will
still fail if we can't GET the file.
> Ahh, v1.6.3 ships with fetch_index() that checks CURLE_OK and returns an
> error(), but that is about .idx file, and it did not have the "do they
> have the corresponding .pack file?" check introduced by 48188c2
> (http-walker: verify remote packs, 2009-06-06), which is what makes the
> server give us 500 error.
Just to clarify: the "check" of CURLE_OK in http-walker.c::fetch_index()
in v1.6.3 is fundamentally different from the check we have in 48188c2
(http-walker: verify remote packs, 2009-06-06).
The first "check" is a full-blooded GET request, and we do get back
actual data (in this case, the pack index file). The second check isn't
a GET request, just an inconsequential HEAD request; we don't get back
any real data.
> Before that check, we ignored a request to
> fetch_index() if we already had one.
48188c2 didn't really remove the check (for the presence of the *.idx
locally), it just pushed it further down.
But being placed so late makes it rather ineffective and useless.
> Why do we even call fetch_index() when we have one? After all, we are
> talking about "git clone" here, so it is not about "we failed once and the
> previous attempt left .idx files we fetched". Why
>
> should we even have .idx file to begin with, that would have protected
> v1.6.3 clients from getting this error?
>
> Unless we are calling fetch_index() on the same .idx file twice from our
> own stupidity, that is.
>
> The same logic now is in fetch_pack_index(), which is called from
> fetch_and_setup_pack_index(). I do not still see how we end up calling
> the function for the same .idx file twice, though.
We should bump up this check before the verify-remote-pack one, I think
there's no mysterious bug here to find.
> In the meantime, I do not think it is a good idea to loosen the error
> checking on our side to accomodate a server in such a (hopefully
> temporary) broken state, however popular it is.
Agreed. I didn't intend my patch to loosen up error checking, merely to
be clearer about what we're looking for. If read in another context
(separate from fixing cloning over github.com), my patch can be seen as
one that clarifies the verify-remote-pack check:
Case 1: A 404 is received. The pack file is not available, so we stop.
Case 2: Our check failed, due to some reason (request failed,
unauthorized, etc). Nothing conclusive about availabilty of
file. Continue anyway.
PS. I wrote 48188c2 with the aim of having http-push.c and http-walker.c
fetch behaviour match each other as closely as possible, and later move
these out into http. At that time, I toyed with the idea of removing
the check. I wondered if the overhead incurred by the HEAD request was
useful, since if there's going to be an error, we would be hit anyway
with a GET. We already do this for almost every other http request
(info/refs, objects/info/packs, etc). But the patch series was meant to
be a refactor job, not a feature/behaviour change, so there you have it.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: tracking branch for a rebase
From: Michael J Gruber @ 2009-09-07 9:06 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Björn Steinbrink, Pete Wyckoff, git
In-Reply-To: <20090907084455.GC17997@coredump.intra.peff.net>
Jeff King venit, vidit, dixit 07.09.2009 10:44:
> On Mon, Sep 07, 2009 at 01:25:38AM -0700, Junio C Hamano wrote:
>
>>> @{^}
>>
>> This _could_ work, although it is rather cryptic.
>
> But an identifier composed entirely of punctuation? It might help
> git catch on with perl programmers. ;)
Right, that was the true agenda hidden only partially behind the plain
association between ^ and up ;)
Michael (having exactly zero perl fu)
P.S.: @ may not be reserved, and neither @^, but 1.7 should allow us to
reserve some symbols/combinations with a "low damage probability".
People may have a@b refnames (git-svn users for sure), but @^?
^ permalink raw reply
* [PATCHv2 2/2] Add url.<base>.pushInsteadOf: URL rewriting for push only
From: Josh Triplett @ 2009-09-07 8:56 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <cover.1252313313.git.josh@joshtriplett.org>
This configuration option allows systematically rewriting fetch-only
URLs to push-capable URLs when used with push. For instance:
[url "ssh://example.org/"]
pushInsteadOf = "git://example.org/"
This will allow clones of "git://example.org/path/to/repo" to
subsequently push to "ssh://example.org/path/to/repo", without manually
configuring pushurl for that remote.
Includes documentation for the new option, bash completion updates, and
test cases (both that pushInsteadOf applies to push and that it does
*not* apply to fetch).
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
Documentation/config.txt | 13 +++++++++++
Documentation/urls.txt | 18 ++++++++++++++++
contrib/completion/git-completion.bash | 2 +-
remote.c | 36 ++++++++++++++++++++++++--------
t/t5516-fetch-push.sh | 31 +++++++++++++++++++++++++++
5 files changed, 90 insertions(+), 10 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5256c7f..38c7086 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1500,6 +1500,19 @@ url.<base>.insteadOf::
never-before-seen repository on the site. When more than one
insteadOf strings match a given URL, the longest match is used.
+url.<base>.pushInsteadOf::
+ Any URL that starts with this value will not be pushed to;
+ instead, it will be rewritten to start with <base>, and the
+ resulting URL will be pushed to. In cases where some site serves
+ a large number of repositories, and serves them with multiple
+ access methods, some of which do not allow push, this feature
+ allows people to specify a pull-only URL and have git
+ automatically use an appropriate URL to push, even for a
+ never-before-seen repository on the site. When more than one
+ pushInsteadOf strings match a given URL, the longest match is
+ used. If a remote has an explicit pushurl, git will ignore this
+ setting for that remote.
+
user.email::
Your email address to be recorded in any newly created commits.
Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 5355ebc..d813ceb 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -67,3 +67,21 @@ For example, with this:
a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".
+If you want to rewrite URLs for push only, you can create a
+configuration section of the form:
+
+------------
+ [url "<actual url base>"]
+ pushInsteadOf = <other url base>
+------------
+
+For example, with this:
+
+------------
+ [url "ssh://example.org/"]
+ pushInsteadOf = git://example.org/
+------------
+
+a URL like "git://example.org/path/to/repo.git" will be rewritten to
+"ssh://example.org/path/to/repo.git" for pushes, but pulls will still
+use the original URL.
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index bf688e1..9859204 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1532,7 +1532,7 @@ _git_config ()
url.*.*)
local pfx="${cur%.*}."
cur="${cur##*.}"
- __gitcomp "insteadof" "$pfx" "$cur"
+ __gitcomp "insteadOf pushInsteadOf" "$pfx" "$cur"
return
;;
esac
diff --git a/remote.c b/remote.c
index ff8e71f..73d33f2 100644
--- a/remote.c
+++ b/remote.c
@@ -47,6 +47,7 @@ static const char *default_remote_name;
static int explicit_default_remote_name;
static struct rewrites rewrites;
+static struct rewrites rewrites_push;
#define BUF_SIZE (2048)
static char buffer[BUF_SIZE];
@@ -104,17 +105,25 @@ static void add_url(struct remote *remote, const char *url)
remote->url[remote->url_nr++] = url;
}
-static void add_url_alias(struct remote *remote, const char *url)
-{
- add_url(remote, alias_url(url, &rewrites));
-}
-
static void add_pushurl(struct remote *remote, const char *pushurl)
{
ALLOC_GROW(remote->pushurl, remote->pushurl_nr + 1, remote->pushurl_alloc);
remote->pushurl[remote->pushurl_nr++] = pushurl;
}
+static void add_pushurl_alias(struct remote *remote, const char *url)
+{
+ const char *pushurl = alias_url(url, &rewrites_push);
+ if (pushurl != url)
+ add_pushurl(remote, pushurl);
+}
+
+static void add_url_alias(struct remote *remote, const char *url)
+{
+ add_url(remote, alias_url(url, &rewrites));
+ add_pushurl_alias(remote, url);
+}
+
static struct remote *make_remote(const char *name, int len)
{
struct remote *ret;
@@ -358,8 +367,13 @@ static int handle_config(const char *key, const char *value, void *cb)
subkey = strrchr(name, '.');
if (!subkey)
return 0;
- rewrite = make_rewrite(&rewrites, name, subkey - name);
if (!strcmp(subkey, ".insteadof")) {
+ rewrite = make_rewrite(&rewrites, name, subkey - name);
+ if (!value)
+ return config_error_nonbool(key);
+ add_instead_of(rewrite, xstrdup(value));
+ } else if (!strcmp(subkey, ".pushinsteadof")) {
+ rewrite = make_rewrite(&rewrites_push, name, subkey - name);
if (!value)
return config_error_nonbool(key);
add_instead_of(rewrite, xstrdup(value));
@@ -433,14 +447,18 @@ static void alias_all_urls(void)
{
int i, j;
for (i = 0; i < remotes_nr; i++) {
+ int add_pushurl_aliases;
if (!remotes[i])
continue;
- for (j = 0; j < remotes[i]->url_nr; j++) {
- remotes[i]->url[j] = alias_url(remotes[i]->url[j], &rewrites);
- }
for (j = 0; j < remotes[i]->pushurl_nr; j++) {
remotes[i]->pushurl[j] = alias_url(remotes[i]->pushurl[j], &rewrites);
}
+ add_pushurl_aliases = remotes[i]->pushurl_nr == 0;
+ for (j = 0; j < remotes[i]->url_nr; j++) {
+ if (add_pushurl_aliases)
+ add_pushurl_alias(remotes[i], remotes[i]->url[j]);
+ remotes[i]->url[j] = alias_url(remotes[i]->url[j], &rewrites);
+ }
}
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 2d2633f..8f455c7 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -122,6 +122,23 @@ test_expect_success 'fetch with insteadOf' '
)
'
+test_expect_success 'fetch with pushInsteadOf (should not rewrite)' '
+ mk_empty &&
+ (
+ TRASH=$(pwd)/ &&
+ cd testrepo &&
+ git config "url.trash/.pushInsteadOf" "$TRASH" &&
+ git config remote.up.url "$TRASH." &&
+ git config remote.up.fetch "refs/heads/*:refs/remotes/origin/*" &&
+ git fetch up &&
+
+ r=$(git show-ref -s --verify refs/remotes/origin/master) &&
+ test "z$r" = "z$the_commit" &&
+
+ test 1 = $(git for-each-ref refs/remotes/origin | wc -l)
+ )
+'
+
test_expect_success 'push without wildcard' '
mk_empty &&
@@ -162,6 +179,20 @@ test_expect_success 'push with insteadOf' '
)
'
+test_expect_success 'push with pushInsteadOf' '
+ mk_empty &&
+ TRASH="$(pwd)/" &&
+ git config "url.$TRASH.pushInsteadOf" trash/ &&
+ git push trash/testrepo refs/heads/master:refs/remotes/origin/master &&
+ (
+ cd testrepo &&
+ r=$(git show-ref -s --verify refs/remotes/origin/master) &&
+ test "z$r" = "z$the_commit" &&
+
+ test 1 = $(git for-each-ref refs/remotes/origin | wc -l)
+ )
+'
+
test_expect_success 'push with matching heads' '
mk_test heads/master &&
--
1.6.3.3
^ permalink raw reply related
* [PATCHv2 1/2] Wrap rewrite globals in a struct in preparation for adding another set
From: Josh Triplett @ 2009-09-07 8:56 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <cover.1252313313.git.josh@joshtriplett.org>
remote.c has a global set of URL rewrites, accessed by alias_url and
make_rewrite. Wrap them in a new "struct rewrites", passed to alias_url
and make_rewrite. This allows adding other sets of rewrites.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
remote.c | 53 ++++++++++++++++++++++++++++-------------------------
1 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/remote.c b/remote.c
index 4b5b905..ff8e71f 100644
--- a/remote.c
+++ b/remote.c
@@ -28,6 +28,11 @@ struct rewrite {
int instead_of_nr;
int instead_of_alloc;
};
+struct rewrites {
+ struct rewrite **rewrite;
+ int rewrite_alloc;
+ int rewrite_nr;
+};
static struct remote **remotes;
static int remotes_alloc;
@@ -41,14 +46,12 @@ static struct branch *current_branch;
static const char *default_remote_name;
static int explicit_default_remote_name;
-static struct rewrite **rewrite;
-static int rewrite_alloc;
-static int rewrite_nr;
+static struct rewrites rewrites;
#define BUF_SIZE (2048)
static char buffer[BUF_SIZE];
-static const char *alias_url(const char *url)
+static const char *alias_url(const char *url, struct rewrites *r)
{
int i, j;
char *ret;
@@ -57,14 +60,14 @@ static const char *alias_url(const char *url)
longest = NULL;
longest_i = -1;
- for (i = 0; i < rewrite_nr; i++) {
- if (!rewrite[i])
+ for (i = 0; i < r->rewrite_nr; i++) {
+ if (!r->rewrite[i])
continue;
- for (j = 0; j < rewrite[i]->instead_of_nr; j++) {
- if (!prefixcmp(url, rewrite[i]->instead_of[j].s) &&
+ for (j = 0; j < r->rewrite[i]->instead_of_nr; j++) {
+ if (!prefixcmp(url, r->rewrite[i]->instead_of[j].s) &&
(!longest ||
- longest->len < rewrite[i]->instead_of[j].len)) {
- longest = &(rewrite[i]->instead_of[j]);
+ longest->len < r->rewrite[i]->instead_of[j].len)) {
+ longest = &(r->rewrite[i]->instead_of[j]);
longest_i = i;
}
}
@@ -72,10 +75,10 @@ static const char *alias_url(const char *url)
if (!longest)
return url;
- ret = xmalloc(rewrite[longest_i]->baselen +
+ ret = xmalloc(r->rewrite[longest_i]->baselen +
(strlen(url) - longest->len) + 1);
- strcpy(ret, rewrite[longest_i]->base);
- strcpy(ret + rewrite[longest_i]->baselen, url + longest->len);
+ strcpy(ret, r->rewrite[longest_i]->base);
+ strcpy(ret + r->rewrite[longest_i]->baselen, url + longest->len);
return ret;
}
@@ -103,7 +106,7 @@ static void add_url(struct remote *remote, const char *url)
static void add_url_alias(struct remote *remote, const char *url)
{
- add_url(remote, alias_url(url));
+ add_url(remote, alias_url(url, &rewrites));
}
static void add_pushurl(struct remote *remote, const char *pushurl)
@@ -169,22 +172,22 @@ static struct branch *make_branch(const char *name, int len)
return ret;
}
-static struct rewrite *make_rewrite(const char *base, int len)
+static struct rewrite *make_rewrite(struct rewrites *r, const char *base, int len)
{
struct rewrite *ret;
int i;
- for (i = 0; i < rewrite_nr; i++) {
+ for (i = 0; i < r->rewrite_nr; i++) {
if (len
- ? (len == rewrite[i]->baselen &&
- !strncmp(base, rewrite[i]->base, len))
- : !strcmp(base, rewrite[i]->base))
- return rewrite[i];
+ ? (len == r->rewrite[i]->baselen &&
+ !strncmp(base, r->rewrite[i]->base, len))
+ : !strcmp(base, r->rewrite[i]->base))
+ return r->rewrite[i];
}
- ALLOC_GROW(rewrite, rewrite_nr + 1, rewrite_alloc);
+ ALLOC_GROW(r->rewrite, r->rewrite_nr + 1, r->rewrite_alloc);
ret = xcalloc(1, sizeof(struct rewrite));
- rewrite[rewrite_nr++] = ret;
+ r->rewrite[r->rewrite_nr++] = ret;
if (len) {
ret->base = xstrndup(base, len);
ret->baselen = len;
@@ -355,7 +358,7 @@ static int handle_config(const char *key, const char *value, void *cb)
subkey = strrchr(name, '.');
if (!subkey)
return 0;
- rewrite = make_rewrite(name, subkey - name);
+ rewrite = make_rewrite(&rewrites, name, subkey - name);
if (!strcmp(subkey, ".insteadof")) {
if (!value)
return config_error_nonbool(key);
@@ -433,10 +436,10 @@ static void alias_all_urls(void)
if (!remotes[i])
continue;
for (j = 0; j < remotes[i]->url_nr; j++) {
- remotes[i]->url[j] = alias_url(remotes[i]->url[j]);
+ remotes[i]->url[j] = alias_url(remotes[i]->url[j], &rewrites);
}
for (j = 0; j < remotes[i]->pushurl_nr; j++) {
- remotes[i]->pushurl[j] = alias_url(remotes[i]->pushurl[j]);
+ remotes[i]->pushurl[j] = alias_url(remotes[i]->pushurl[j], &rewrites);
}
}
}
--
1.6.3.3
^ permalink raw reply related
* [PATCHv2 0/2] Add url.<base>.pushInsteadOf: URL rewriting for push only
From: Josh Triplett @ 2009-09-07 8:55 UTC (permalink / raw)
To: git, gitster
Many sites host repositories via both git:// for fetch-only anonymous
access and ssh:// for push-capable access. The "insteadOf" mechanism
makes it straightforward to substitute the push-capable URLs for the
pull-only URLs, which proves convenient when the site hosts many
repositories using the same URL scheme. However, if you use such a
substitution and you cannot use the ssh:// URLs (either because you
don't have SSH access or you don't have permission to a particular
repository), you cannot clone or fetch either, even though you could do
so via the git:// URLs. A situation like this arises when sharing git
configuration files between systems, of which only a few have SSH access
to repositories.
"pushurl" provides a way to specify URLs used only for push, but this
requires configuring a pushurl for each such repository. As in the
rationale for insteadOf, it makes sense to configure this for all
repositories hosted on a given system at once.
This patch series adds a new "pushInsteadOf" option to go with
"insteadOf". pushInsteadOf allows systematically rewriting fetch-only
URLs to push-capable URLs when used with push. For instance:
[url "ssh://example.org/"]
pushInsteadOf = "git://example.org/"
This will allow clones of "git://example.org/path/to/repo" to
subsequently push to "ssh://example.org/path/to/repo", without manually
configuring pushurl for that remote.
Includes documentation for the new option, bash completion updates, and
test cases (both that pushInsteadOf applies to push and that it does
*not* apply to fetch).
Changes in v2:
- Don't add implicit pushurls from pushInsteadOf to remotes with explicit
pushurls (suggested by Junio).
- Fix pushInsteadOf rewrites to occur before insteadOf rewrites, to avoid
basing the pushInsteadOf rewrites on the rewritten URLs.
Josh Triplett (2):
Wrap rewrite globals in a struct in preparation for adding another set
Add url.<base>.pushInsteadOf: URL rewriting for push only
Documentation/config.txt | 13 +++++
Documentation/urls.txt | 18 +++++++
contrib/completion/git-completion.bash | 2 +-
remote.c | 83 ++++++++++++++++++++------------
t/t5516-fetch-push.sh | 31 ++++++++++++
5 files changed, 115 insertions(+), 32 deletions(-)
^ permalink raw reply
* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-07 8:54 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Nanako Shiraishi, Junio C Hamano, Teemu Likonen, Git
In-Reply-To: <vpqeiqjf90u.fsf@bauges.imag.fr>
On Mon, Sep 07, 2009 at 10:34:25AM +0200, Matthieu Moy wrote:
> > So really they are two different conceptual types of message. And while
> > I have no problem with an argument of "I _personally_ find this clutter
> > and would like to configure it off", I don't think such an option should
> > go under "advice.*". My patch had "message.all" (which will become
> > "advice.all")
>
> To me, this is an argument in favor of keeping "message", to allow the
> same mechanism for these different types of messages.
>
> But I think the individual message.* should not be just true/false
> switch, but could be always/auto/never :
>
> - always: show the message, regardless of message.all
> - auto (the default): rely on message.all to decide whether to show
> the message
> - never: never show it.
>
> So you could say "message.all = false" and "message.resetShowsNewHead
> = always".
>
> But maybe that's just overkill, dunno...
I'm not sure it solves the problem. The point of "message.all" was to
easily say "I'm an expert, so turn off useless advice". But now I would
have to manually re-enable any messages that I _do_ want to see. And of
course I don't see them to know that I want them, so I have to read
through the config documentation and decide on each one.
At that point, why not just get rid of "message.all" and simply say
"manually turn off the messages you don't like". Then the user can
either go through the config manually as above, or they can wait until
they become annoyed with a particular message and turn it off (and
hopefully our naming is good enough that they can easily figure out
which one it was :) ).
So I think "be verbose, but let the user quiet us" is probably
better than "be quiet, but let the user make us louder", because it is
easier to discover verbose things. Which implies to me that
"message.all", if it exists at all, should be limited in scope to just
advice.
In fact, you could mix many types in the message.* hierarchy and simply
call the umbrella variable message.advice. But that is semantically
equivalent to having advice.{all,*} and other_type_of_message.{all,*}.
-Peff
^ permalink raw reply
* [PATCH] grep: fix exit status if external_grep() returns error
From: Clemens Buchacher @ 2009-09-07 8:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <7v3a6zu1dk.fsf@alter.siamese.dyndns.org>
On Sun, Sep 06, 2009 at 03:58:15PM -0700, Junio C Hamano wrote:
> Your patch is queued in 'pu', but it seems to break the exit status in a
> strange way with my limited test.
[...]
> The command should not give different exit status depending on the
> destination of standard output stream.
I could also reproduce this in master using
:~/git/t$ git grep --no-color not-going-to-match .; echo $?
The problem is a small bug in grep_cache(), which is triggered here because
external_grep() cannot deal with relative paths (not sure why that's the
case though). Fix below.
Clemens
--o<--
If external_grep() is called and returns an error, grep_cache() mistakenly
reported a hit, even if there were none. The bug can be triggered by
calling "git grep --no-color" from a subdirectory.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
builtin-grep.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index ad0e0a5..b577738 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -500,9 +500,9 @@ static int grep_cache(struct grep_opt *opt, const char **paths, int cached,
* be a lot more optimized
*/
if (!cached && external_grep_allowed) {
- hit = external_grep(opt, paths, cached);
- if (hit >= 0)
- return hit;
+ int ret = external_grep(opt, paths, cached);
+ if (ret >= 0)
+ return ret;
}
#endif
--
1.6.4.2.266.gbaa17
^ permalink raw reply related
* Re: tracking branch for a rebase
From: Jeff King @ 2009-09-07 8:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Björn Steinbrink, Pete Wyckoff, git
In-Reply-To: <7vzl97xit9.fsf@alter.siamese.dyndns.org>
On Mon, Sep 07, 2009 at 01:25:38AM -0700, Junio C Hamano wrote:
> > @{^}
>
> This _could_ work, although it is rather cryptic.
But an identifier composed entirely of punctuation? It might help git
catch on with perl programmers. ;)
-Peff
^ permalink raw reply
* Re: tracking branch for a rebase
From: Jeff King @ 2009-09-07 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, Michael J Gruber, Pete Wyckoff, git
In-Reply-To: <7vfxaz9wfi.fsf@alter.siamese.dyndns.org>
On Sun, Sep 06, 2009 at 10:05:21PM -0700, Junio C Hamano wrote:
> At-mark currently is reserved for anything that uses reflog, but we can
> say that it is to specify operations on refs (as opposed to caret and
> tilde are to specify operations on object names).
I assume you meant that @{} is reserved; my reading of the previous
discussion was that "foo@bar" is still valid.
> It specifies what ref to work on with the operand on its left side (and an
> empty string stands for "HEAD"), and what operation is done to it by what
> is in {} on the right side of it. This view is quite consistent with the
> following existing uses of the notation:
>
> ref@{number} -- nth reflog entry
> ref@{time} -- ref back then
> @{-number} -- nth branch switching
>
> So perhaps ref@{upstream}, or any string that is not a number and cannot
> be time, can trigger the magic operation on the ref with ref@{magic}
> syntax?
I think using @{} is a reasonable extension format. It's easy to read
and syntactically obvious. We need to watch out for conflicts with
things that might be valid times, but that is an easy thing to check
when adding new keywords. The only danger would be some extension
specifier that used arbitrary input, but that would probably be prefixed
with a keyword (and I can't even think of an example extension that
would want arbitrary input).
My only two complaints with ref@{upstream} are (and I don't think either
is a show-stopper, but maybe something we can improve on).
1. It is a nice abstraction, but it doesn't save typing in most cases.
"origin" is shorter than "master@{upstream}". One of the desired
features in the last thread was that it be very short (which isn't
to say we can't introduce @{upstream} _now_ and add a shorter
synonym later on).
2. I assume @{upstream} will be equivalent to HEAD@{upstream}. What
should it do? The most useful thing to me would be to find the
upstream for the current branch. But that is actually quite
different from how HEAD@{1} works, which looks at the reflog for
HEAD and not the branch.
Maybe this is an inconsistency we can live with. The features are,
after all, only syntactically related. I was just hoping to keep
things as simple as possible for users to understand (and they
often take semantic clues from syntax).
And some final thinking out loud in this area (i.e., these ideas are, I
think, somewhat half baked):
We already have some reserved uppercase ref names like HEAD, FETCH_HEAD,
ORIG_HEAD, and MERGE_HEAD. One option would be to declare all-caps
names as reserved and allow UPSTREAM for the feature in question. I can
think of two arguments against it:
1. The obvious one, that somebody somewhere is using all-caps and we
are breaking their setup.
2. It is not syntactically obvious to the user that it is not a real
ref, but rather a magic name. Users are accustomed to punctuation
introducing magic, so @{upstream} is probably better in that regard.
So I think that is a bad idea. But what about allowing "ref aliases"?
Obviously a static one like "f" for "foo" is kind of lame. But if you
could use the extension syntax, like:
git config refalias.% '@{upstream}'
then we can let people set up whatever shorthand they think is sane (and
without worrying about clobbering unlikely-but-allowed setups, since
they are in control of their setup).
Like I said, I am not sure that is not half-baked. ;)
-Peff
^ permalink raw reply
* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Matthieu Moy @ 2009-09-07 8:34 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, Junio C Hamano, Teemu Likonen, Git
In-Reply-To: <20090907082430.GA17997@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Sep 07, 2009 at 09:44:57AM +0900, Nanako Shiraishi wrote:
>
>> You may be fixated at the sha1 part of the message when you find this
>> message annoying, but I disagree strongly. I always appreciate the
>> assurance this message gives me that I counted the number of commits
>> correctly, whether I say HEAD^^^^ or HEAD~7.
>
> Let me add a "me too" to Nanako's comments.
I guess it depends on one's workflow. If you usually cut-and-paste
sha1's, then the message is superfluous, while if you usually use
magic revspec, it is useful.
So, it's probably a good idea to make this configurable.
> So really they are two different conceptual types of message. And while
> I have no problem with an argument of "I _personally_ find this clutter
> and would like to configure it off", I don't think such an option should
> go under "advice.*". My patch had "message.all" (which will become
> "advice.all")
To me, this is an argument in favor of keeping "message", to allow the
same mechanism for these different types of messages.
But I think the individual message.* should not be just true/false
switch, but could be always/auto/never :
- always: show the message, regardless of message.all
- auto (the default): rely on message.all to decide whether to show
the message
- never: never show it.
So you could say "message.all = false" and "message.resetShowsNewHead
= always".
But maybe that's just overkill, dunno...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: tracking branch for a rebase
From: Junio C Hamano @ 2009-09-07 8:25 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, Björn Steinbrink, Pete Wyckoff, git
In-Reply-To: <4AA4C0CE.2070300@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> @^
"@" itself is not reserved, even though "@{" is, so this is not an
option.
> @{^}
This _could_ work, although it is rather cryptic.
^ permalink raw reply
* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-07 8:24 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Matthieu Moy, Teemu Likonen, Git
In-Reply-To: <20090907094457.6117@nanako3.lavabit.com>
On Mon, Sep 07, 2009 at 09:44:57AM +0900, Nanako Shiraishi wrote:
> > Speaking of which, has anybody felt annoyed by this message?
> >
> > $ git reset --hard HEAD^^
> > HEAD is now at 3fb9d58 Do not scramble password read from .cvspass
> >
> > This is not "maybe you should try this", but I would consider that it
> > falls into the same "I see you are trying to be helpful, but I know what I
> > am doing, and you are stealing screen real estate from me without helping
> > me at all, thank you very much" category.
>
> You may be fixated at the sha1 part of the message when you find this
> message annoying, but I disagree strongly. I always appreciate the
> assurance this message gives me that I counted the number of commits
> correctly, whether I say HEAD^^^^ or HEAD~7.
Let me add a "me too" to Nanako's comments. This assurance has actually
saved me in the past from accidentally going to the wrong commit (just
the other day I did a rebase followed by "git reset --hard HEAD@{1}",
when of course what I meant was "git reset --hard master@{1}".
I think this type of message is different from the other "advice"
messages.
In the case of the push non-fast-forward message and the status "here is
how you stage" comments, those messages are not specific to this exact
situation. They are general advice for "if you do not understand or need
a reminder of how git works, this is it." Experienced users know how git
works, so the messages are just clutter.
This message, on the other hand, tells you about this _specific_
instance. So even if you have mastered git, the information can reassure
you that you have gone to the intended commit (and yes, I have actually
gone to the wrong commit before, noticed it via this reset message, and
corrected the situation).
So really they are two different conceptual types of message. And while
I have no problem with an argument of "I _personally_ find this clutter
and would like to configure it off", I don't think such an option should
go under "advice.*". My patch had "message.all" (which will become
"advice.all") to turn off all advice messages, which can act as a sort
of "I am an expert" switch. But because this type of message is
conceptually different, it should not be lumped in with the others.
OTOH, I am open to arguments against "advice.all"; maybe it is a good
thing for users to manually say "this message is annoying me, and
therefore I am now an expert in this particular area". It's not like
there are more than two. ;)
-Peff
^ 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