* Re: How to clone git repository with git-svn meta-data included?
From: Sam Vilain @ 2008-12-09 9:08 UTC (permalink / raw)
To: Grzegorz Kossakowski; +Cc: Peter Harris, Michael J Gruber, git
In-Reply-To: <493D6AE9.6020504@tuffmail.com>
On Mon, 2008-12-08 at 19:43 +0100, Grzegorz Kossakowski wrote:
> > Yes. The rfoo = sha1hash part is git-svn rebuilding its index.
> > "Current branch master is up to date" is git-svn calling "git rebase
> > <svn-branch>", and git saying that there is nothing to do, since there
> > have been no svn commits to that branch since the last time you ran
> > git svn rebase (or since you cloned the git mirror, or since the last
> > time the git mirror pulled from svn).
>
> Thanks for confirmation and explanation.
>
> The remaining question is who should address this issue with non-existing trunk ref? Should I ask
> Jukka, who maintains svn mirrors, to put instruction into his scripts that will add trunk reference?
It's up to the git-svn user to make sure that they prepare the refs to
be what git-svn expects. This is something probably requiring more
documentation and/or git-svn features to be easier.
> Would it be the best practice?
Well, obscure stuff should never really be best practice. The best practice
is to have a single git repository that is where the svn -> git migration
happens. And git-svn could perhaps auto-init based on information in the
commit log or something. Best practice is to enhance the tool to work the
way it Should(tm) :)
Sam
^ permalink raw reply
* Re: is gitosis secure?
From: Sam Vilain @ 2008-12-09 9:04 UTC (permalink / raw)
To: Thomas Koch; +Cc: Git Mailing List, dabe
In-Reply-To: <200812090956.48613.thomas@koch.ro>
On Tue, 2008-12-09 at 09:56 +0100, Thomas Koch wrote:
> Sorry for the shameless subject, but I presented gitosis yesterday to
> our sysadmin and he wasn't much delighted to learn, that write access to
> repositories hosted with gitosis would need SSH access.
>
> So could you help me out in this discussion, whether to use or not to
> use gitosis?
> Our admin would prefer to not open SSH at all outside our LAN, but
> developers would need to have write access also outside the office.
Restricted unix shells are a technology which has been proven secure for
decades now. If you use git-shell, you are keeping the secure part of
SSH - the authentication and encryption - and restricting the SSH access
part to the bare minimum required for useful access to the required
services.
ie ... it all comes down to the shell you give those 'login' users as to
what they can do.
Sam.
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Grzegorz Kossakowski @ 2008-12-09 20:57 UTC (permalink / raw)
To: Sam Vilain, git
In-Reply-To: <1228813734.28186.77.camel@maia.lan>
Sam Vilain pisze:
> It's up to the git-svn user to make sure that they prepare the refs to
> be what git-svn expects. This is something probably requiring more
> documentation and/or git-svn features to be easier.
What I was asking if we should add trunk ref to svn mirror so others cloning it will have
'origin/trunk' reference created automatically during clone process so no extra steps would be needed.
To be honest, I don't understand how Git exactly handles all this refs mapping and rewriting (e.g.
during cloning). Having said that, I cannot foresee all possible implications of choosing particular
method of solving current issues thus asking you.
>> Would it be the best practice?
>
> Well, obscure stuff should never really be best practice. The best practice
> is to have a single git repository that is where the svn -> git migration
> happens. And git-svn could perhaps auto-init based on information in the
> commit log or something. Best practice is to enhance the tool to work the
> way it Should(tm) :)
Cannot follow you here. We want single svn mirror but at the same time we want to our committers to
be able to push back to svn. What has been already proposed satisfies my need apart from the fact
that currently there is small problem with our mirror setup.
--
Best regards,
Grzegorz Kossakowski
^ permalink raw reply
* Re: git fsck segmentation fault
From: Martin Koegler @ 2008-12-09 21:57 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Simon Hausmann, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812091408560.14328@xanadu.home>
On Tue, Dec 09, 2008 at 02:09:58PM -0500, Nicolas Pitre wrote:
> Has this been looked at? Martin?
I have not noticed this message.
> #54 0x0000000000493c6d in parse_tree (item=0x20d0178) at tree.c:224
> #55 0x0000000000424ca2 in mark_object (obj=0x20d0178, type=2, data=<value
> optimized out>) at builtin-fsck.c:102
> #56 0x0000000000468d1c in fsck_walk (obj=<value optimized out>, walk=0x424af0
> <mark_object>, data=0x20d0128) at fsck.c:26
> #57 0x0000000000424cba in mark_object (obj=0x20d0128, type=2, data=<value
> optimized out>) at builtin-fsck.c:105
> #58 0x0000000000468d1c in fsck_walk (obj=<value optimized out>, walk=0x424af0
> <mark_object>, data=0x1edb448) at fsck.c:26
> #59 0x0000000000424cba in mark_object (obj=0x1edb448, type=2, data=<value
> optimized out>) at builtin-fsck.c:105
> #60 0x0000000000468d1c in fsck_walk (obj=<value optimized out>, walk=0x424af0
> <mark_object>, data=0x1edb420) at fsck.c:26
> #61 0x0000000000424cba in mark_object (obj=0x1edb420, type=2, data=<value
> optimized out>) at builtin-fsck.c:105
> #62 0x0000000000468bf9 in fsck_walk (obj=0x241a750, walk=0x424af0
> <mark_object>, data=0x241a750) at fsck.c:50
> #63 0x0000000000424b7d in mark_object (obj=0x241a750, type=1, data=<value
> optimized out>) at builtin-fsck.c:105
> #64 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0
> <mark_object>, data=0x241a708) at fsck.c:57
> #65 0x0000000000424b7d in mark_object (obj=0x241a708, type=1, data=<value
> optimized out>) at builtin-fsck.c:105
> #66 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0
> <mark_object>, data=0x4dea0b0) at fsck.c:57
> #67 0x0000000000424b7d in mark_object (obj=0x4dea0b0, type=1, data=<value
> optimized out>) at builtin-fsck.c:105
> #68 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0
> <mark_object>, data=0x488ff78) at fsck.c:57
> #69 0x0000000000424b7d in mark_object (obj=0x488ff78, type=1, data=<value
> optimized out>) at builtin-fsck.c:105
> #70 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0
> <mark_object>, data=0x488bd18) at fsck.c:57
> #71 0x0000000000424b7d in mark_object (obj=0x488bd18, type=1, data=<value
> optimized out>) at builtin-fsck.c:105
> #72 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0
> <mark_object>, data=0x313c0b0) at fsck.c:57
> #73 0x0000000000424b7d in mark_object (obj=0x313c0b0, type=1, data=<value
> optimized out>) at builtin-fsck.c:105
> [recursion between line 105 and 57]
If I look at the backtrace, nothing seems wrong. The obj pointers for
mark_object are all different, so its not stuck in a loop. If you look
at type, you will see that it traverses commits (type=1) untils
#63. Then it traverses trees (type=2).
At my option, there is a commit with a very long ancestory (~40.000
[stack frame count/2]). As we do depth first search for the reachability
check, we need about 80.000 frames.
I suggest, that you retry with a very much bigger stack (ulimit -s).
mfg Martin Kögler
^ permalink raw reply
* Re: Forcing --no-ff on pull
From: Daniel Barkalow @ 2008-12-09 22:32 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: Nanako Shiraishi, git
In-Reply-To: <1228819087.18611.73.camel@starfruit.local>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3180 bytes --]
On Tue, 9 Dec 2008, R. Tyler Ballance wrote:
> On Tue, 2008-12-09 at 19:17 +0900, Nanako Shiraishi wrote:
> > Quoting "R. Tyler Ballance" <tyler@slide.com>:
> >
> > > The most common use-case involves a user merging a project branch into a
> > > stabilization branch (`git checkout stable && git pull . project`) in
> > > such a way that no merge commit is generated. Of course, without
> > > thinking they'll push these changes up to the centralized repository.
> > > Not 15 minutes later they realize "ruh roh! I didn't want to do that"
> >
> > Why does the user not want to fast-forward, if the merge she wants to do is actually a fast-forward?
>
> I agree with you, this is more about preventing coworkers who are too
> lazy to understand the entirety of what they're doing from hurting the
> workflow of "the rest of us". It's a technically solution to a people
> problem (I understand technology far more than people ;))
>
> Consider the following scenarion:
> % git checkout -b project
> % <work>
> % git commit -am "A"
> % <work>
> % git commit -am "B"
> % <work>
> % git commit -am "C"
> % <work>
> % git commit -am "D"
> % git checkout stable
> % git pull . project
> % <fast-forward>
> % git push origin stable
>
> At this point, QA is involved and what can happen is that QA realizes
> that this code is *not* stable and *never* should have been brought into
> the stable branch.
How do you prevent the (IMHO more likely) case of:
% git checkout -b project
% git checkout stable
<fix some bug in stable>
% git commit -a
<forget to switch branches back>
<work>
% git commit -am "A"
<work>
% git commit -am "B"
...
% git push origin stable
That is, the developer makes a whole bunch of inappropriate commits on
their stable branch instead of their project branch and then pushes it out
(perhaps as part of a push rule, or thinking only the bug fix went there).
I suspect that "pull" step there isn't the point where things are going
wrong.
If you've actually got QA in the process, have developers push to a
per-developer location and send a pull request to QA. QA can reject bad
changes instead of putting them into the stable branch at all, and then
they can reply to the pull requests with snide comments instead of having
to beat up the developers, because the developer doesn't inconvenience
anybody (except QA, whose job is to be inconvenienced by developers).
> I'm less concerned at this point, the company switched entirely to Git
> two weeks ago, with the history containing possible unwanted merges. I'm
> more concerned however with LazyDeveloper inadvertently polluting stable
> branches as LazyDeveloper does not yet fully grasp the concepts that Git
> offers
I think such developers are more likely to push some bad commits to
"stable" directly than they are to make their bad commits on a branch,
merge it (fast-forward or otherwise) and push the result. It's also easy
to discover:
% git push origin project:stable
And not generate a merge commit simply by virtue of not merging branches.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH 0/3] gitweb: Improve git_blame in preparation for incremental blame
From: Jakub Narebski @ 2008-12-09 22:43 UTC (permalink / raw)
To: git; +Cc: Luben Tuikov
The following series implements a few improvements to git_blame code
and 'blame' view output to prepare for WIP/RFC patch adding incremental
blame output to gitweb using AJAX (JavaScript and XMLHttpRequest); the
code in question is based on code by Petr Baudis from 26 Aug 2007
http://permalink.gmane.org/gmane.comp.version-control.git/56657
which in turn was based on Fredrik Kuivinen proof of concept patch.
The first patch in series (moving id to tr element) is needed in
blame_incremental, and it makes it easier to use DOM to manipulate
gitweb blame output.
Second patch is about what I have noticed when examining git_blame
code.
The last patch is not necessarily required; but please tell me if it
is to be accepted or to be dropped, to know whether to base
incremental blame on it.
---
Jakub Narebski (3):
gitweb: A bit of code cleanup in git_blame()
gitweb: Cache $parent_commit info in git_blame()
gitweb: Move 'lineno' id from link to row element in git_blame
gitweb/gitweb.perl | 84 ++++++++++++++++++++++++++++++----------------------
1 files changed, 49 insertions(+), 35 deletions(-)
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* [PATCH 1/3] gitweb: Move 'lineno' id from link to row element in git_blame
From: Jakub Narebski @ 2008-12-09 22:46 UTC (permalink / raw)
To: git; +Cc: Luben Tuikov, Jakub Narebski
In-Reply-To: <20081209223703.28106.29198.stgit@localhost.localdomain>
Move l<line number> ID from <a> link element inside table row (inside
cell element for column with line numbers), to encompassing <tr> table
row element. It was done to make it easier to manipulate result HTML
with DOM, and to be able write 'blame_incremental' view with the same,
or nearly the same result.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
For blame_incremental I need easy way to manipulate rows of blame
table, to add information about blamed commits as it arrives.
So there it is.
gitweb/gitweb.perl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6eb370d..1b800f4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4645,7 +4645,7 @@ HTML
if ($group_size) {
$current_color = ++$current_color % $num_colors;
}
- print "<tr class=\"$rev_color[$current_color]\">\n";
+ print "<tr id=\"l$lineno\" class=\"$rev_color[$current_color]\">\n";
if ($group_size) {
print "<td class=\"sha1\"";
print " title=\"". esc_html($author) . ", $date\"";
@@ -4667,7 +4667,6 @@ HTML
hash_base => $parent_commit);
print "<td class=\"linenr\">";
print $cgi->a({ -href => "$blamed#l$orig_lineno",
- -id => "l$lineno",
-class => "linenr" },
esc_html($lineno));
print "</td>";
^ permalink raw reply related
* [PATCH 2/3] gitweb: Cache $parent_commit info in git_blame()
From: Jakub Narebski @ 2008-12-09 22:48 UTC (permalink / raw)
To: git; +Cc: Luben Tuikov, Jakub Narebski
In-Reply-To: <20081209223703.28106.29198.stgit@localhost.localdomain>
Luben Tuikov changed 'lineno' link from leading to commit which lead
to current version of given block of lines, to leading to parent of
this commit in 244a70e (Blame "linenr" link jumps to previous state at
"orig_lineno"). This supposedly made data mining possible (or just
better).
Unfortunately the implementation in 244a70e used one call for
git-rev-parse to find parent revision per line in file, instead of
using long lived "git cat-file --batch-check" (which might not existed
then), or changing validate_refname to validate_revision and made it
accept <rev>^, <rev>^^, <rev>^^^ etc. syntax.
This patch attempts to migitate issue a bit by caching $parent_commit
info in %metainfo, which makes gitweb to call git-rev-parse only once
per unique commit in blame output.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
That is what I have noticed during browsing git_blame() code.
We can change it to even more effective implementation (like the ones
proposed above in the commit message) later.
Indenting is cause for artifically large diff
gitweb/gitweb.perl | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1b800f4..916396a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4657,11 +4657,17 @@ HTML
esc_html($rev));
print "</td>\n";
}
- open (my $dd, "-|", git_cmd(), "rev-parse", "$full_rev^")
- or die_error(500, "Open git-rev-parse failed");
- my $parent_commit = <$dd>;
- close $dd;
- chomp($parent_commit);
+ my $parent_commit;
+ if (!exists $meta->{'parent'}) {
+ open (my $dd, "-|", git_cmd(), "rev-parse", "$full_rev^")
+ or die_error(500, "Open git-rev-parse failed");
+ $parent_commit = <$dd>;
+ close $dd;
+ chomp($parent_commit);
+ $meta->{'parent'} = $parent_commit;
+ } else {
+ $parent_commit = $meta->{'parent'};
+ }
my $blamed = href(action => 'blame',
file_name => $meta->{'filename'},
hash_base => $parent_commit);
^ permalink raw reply related
* [PATCH 3/3] gitweb: A bit of code cleanup in git_blame()
From: Jakub Narebski @ 2008-12-09 22:48 UTC (permalink / raw)
To: git; +Cc: Luben Tuikov, Jakub Narebski
In-Reply-To: <20081209223703.28106.29198.stgit@localhost.localdomain>
Among others:
* move variable declaration closer to the place it is set and used,
if possible,
* uniquify and simplify coding style a bit, which includes removing
unnecessary '()'.
* check type only if $hash was defined, as otherwise from the way
git_get_hash_by_path() is called (and works), we know that it is
a blob,
* use modern calling convention for git-blame,
* remove unused variable,
* don't use implicit variables ($_),
* add some comments
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Not stricly necessary... but the code looked not very nice
gitweb/gitweb.perl | 65 ++++++++++++++++++++++++++++++----------------------
1 files changed, 37 insertions(+), 28 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 916396a..68aa3f8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4575,28 +4575,32 @@ sub git_tag {
}
sub git_blame {
- my $fd;
- my $ftype;
-
+ # permissions
gitweb_check_feature('blame')
- or die_error(403, "Blame view not allowed");
+ or die_error(403, "Blame view not allowed");
+ # error checking
die_error(400, "No file name given") unless $file_name;
$hash_base ||= git_get_head_hash($project);
- die_error(404, "Couldn't find base commit") unless ($hash_base);
+ die_error(404, "Couldn't find base commit") unless $hash_base;
my %co = parse_commit($hash_base)
or die_error(404, "Commit not found");
if (!defined $hash) {
$hash = git_get_hash_by_path($hash_base, $file_name, "blob")
or die_error(404, "Error looking up file");
+ } else {
+ my $ftype = git_get_type($hash);
+ if ($ftype !~ "blob") {
+ die_error(400, "Object is not a blob");
+ }
}
- $ftype = git_get_type($hash);
- if ($ftype !~ "blob") {
- die_error(400, "Object is not a blob");
- }
- open ($fd, "-|", git_cmd(), "blame", '-p', '--',
- $file_name, $hash_base)
+
+ # run git-blame --porcelain
+ open my $fd, "-|", git_cmd(), "blame", '-p',
+ $hash_base, '--', $file_name
or die_error(500, "Open git-blame failed");
+
+ # page header
git_header_html();
my $formats_nav =
$cgi->a({-href => href(action=>"blob", -replay=>1)},
@@ -4610,40 +4614,43 @@ sub git_blame {
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
git_print_page_path($file_name, $ftype, $hash_base);
- my @rev_color = (qw(light2 dark2));
+
+ # page body
+ my @rev_color = qw(light2 dark2);
my $num_colors = scalar(@rev_color);
my $current_color = 0;
- my $last_rev;
+ my %metainfo = ();
+
print <<HTML;
<div class="page_body">
<table class="blame">
<tr><th>Commit</th><th>Line</th><th>Data</th></tr>
HTML
- my %metainfo = ();
- while (1) {
- $_ = <$fd>;
- last unless defined $_;
+ LINE:
+ while (my $line = <$fd>) {
+ chomp $line;
+ # the header: <SHA-1> <src lineno> <dst lineno> [<lines in group>]
+ # no <lines in group> for subsequent lines in group of lines
my ($full_rev, $orig_lineno, $lineno, $group_size) =
- /^([0-9a-f]{40}) (\d+) (\d+)(?: (\d+))?$/;
+ ($line =~ /^([0-9a-f]{40}) (\d+) (\d+)(?: (\d+))?$/);
if (!exists $metainfo{$full_rev}) {
$metainfo{$full_rev} = {};
}
my $meta = $metainfo{$full_rev};
- while (<$fd>) {
- last if (s/^\t//);
- if (/^(\S+) (.*)$/) {
+ while (my $data = <$fd>) {
+ chomp $data;
+ last if ($data =~ s/^\t//); # contents of line
+ if ($data =~ /^(\S+) (.*)$/) {
$meta->{$1} = $2;
}
}
- my $data = $_;
- chomp $data;
- my $rev = substr($full_rev, 0, 8);
+ my $short_rev = substr($full_rev, 0, 8);
my $author = $meta->{'author'};
- my %date = parse_date($meta->{'author-time'},
- $meta->{'author-tz'});
+ my %date =
+ parse_date($meta->{'author-time'}, $meta->{'author-tz'});
my $date = $date{'iso-tz'};
if ($group_size) {
- $current_color = ++$current_color % $num_colors;
+ $current_color = ($current_color + 1) % $num_colors;
}
print "<tr id=\"l$lineno\" class=\"$rev_color[$current_color]\">\n";
if ($group_size) {
@@ -4654,7 +4661,7 @@ HTML
print $cgi->a({-href => href(action=>"commit",
hash=>$full_rev,
file_name=>$file_name)},
- esc_html($rev));
+ esc_html($short_rev));
print "</td>\n";
}
my $parent_commit;
@@ -4683,6 +4690,8 @@ HTML
print "</div>";
close $fd
or print "Reading blob failed\n";
+
+ # page footer
git_footer_html();
}
^ permalink raw reply related
* start with none of your own money
From: Jason Corley @ 2008-12-09 23:44 UTC (permalink / raw)
To: git
go to http://investors2009.com/ to learn to buy residential and commercial real estate with none of your own money.
This email was sent from the Real Estate Investment Academy. To be removed please type your email address on the following site http://investors2009.com/remove/
--------------------------------------------
.
^ permalink raw reply
* Recovering from epic fail (deleted .git/objects/pack)
From: R. Tyler Ballance @ 2008-12-10 0:11 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
I really wish I didn't have to ask this question, as we discussed in
#git early this morning, whiskey is the likely answer.
For unexplainable reasons one of our sysadmins got trigger-happy when he
tried to prune a temp_pack file generated and left in a
developer's .git/ directory after a git operation aborted (disk quota
exceeded)
As a result, the sysadmin killed the developers
entire .git/objects/pack/ directory. (insert copious amounts of whiskey
here)
He did not however delete all the other contents of .git/objects (00/,
01/, etc)
Is there a feasible way that I can properly recover
the .git/objects/pack directory such that the developer who had their
last two weeks of local work thrashed can get it back?
Anything that can help (other than pummeling the sysadmin) would be
appreciated
Cheers
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Recovering from epic fail (deleted .git/objects/pack)
From: Junio C Hamano @ 2008-12-10 0:19 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1228867861.14165.19.camel@starfruit.local>
"R. Tyler Ballance" <tyler@slide.com> writes:
> I really wish I didn't have to ask this question, as we discussed in
> #git early this morning, whiskey is the likely answer.
>
> For unexplainable reasons one of our sysadmins got trigger-happy when he
> tried to prune a temp_pack file generated and left in a
> developer's .git/ directory after a git operation aborted (disk quota
> exceeded)
>
> As a result, the sysadmin killed the developers
> entire .git/objects/pack/ directory. (insert copious amounts of whiskey
> here)
>
> He did not however delete all the other contents of .git/objects (00/,
> 01/, etc)
>
> Is there a feasible way that I can properly recover
> the .git/objects/pack directory such that the developer who had their
> last two weeks of local work thrashed can get it back?
I do not know about "feasible" and "properly", but ...
(0) take backup of the repository of this unfortunate developer.
(1) make a fresh clone of the central repository that this unfortunate
developer's work started out from.
(2) copy the contents of the .git/objects/pack/ of that clone to the
developer's .git/objects/pack/.
See if "fsck --full" complains after that. If the repository was not
repacked during that period, all objects created by the activity by the
unfortunate developer would be loose, so ...
^ permalink raw reply
* Re: [PATCH 3/3] gitweb: A bit of code cleanup in git_blame()
From: Jakub Narebski @ 2008-12-10 2:13 UTC (permalink / raw)
To: git
In-Reply-To: <20081209224814.28106.83387.stgit@localhost.localdomain>
Jakub Narebski wrote:
I'm sorry, there should be
+ my $ftype = "blob";
> if (!defined $hash) {
> $hash = git_get_hash_by_path($hash_base, $file_name, "blob")
> or die_error(404, "Error looking up file");
> + } else {
> + $ftype = git_get_type($hash);
> + if ($ftype !~ "blob") {
> + die_error(400, "Object is not a blob");
> + }
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/3] gitweb: Cache $parent_commit info in git_blame()
From: Nanako Shiraishi @ 2008-12-10 3:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Luben Tuikov
In-Reply-To: <20081209224622.28106.89325.stgit@localhost.localdomain>
Quoting Jakub Narebski <jnareb@gmail.com>:
> Unfortunately the implementation in 244a70e used one call for
> git-rev-parse to find parent revision per line in file, instead of
> using long lived "git cat-file --batch-check" (which might not existed
> then), or changing validate_refname to validate_revision and made it
> accept <rev>^, <rev>^^, <rev>^^^ etc. syntax.
Could you substantiate why this is "Unfortunate"? Is the new implementation faster? By how much?
When "previous" commit information is available in the output from "git blame", can you make use of it?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: Move 'lineno' id from link to row element in git_blame
From: Luben Tuikov @ 2008-12-10 5:55 UTC (permalink / raw)
To: git, Jakub Narebski
In-Reply-To: <20081209224330.28106.18301.stgit@localhost.localdomain>
--- On Tue, 12/9/08, Jakub Narebski <jnareb@gmail.com> wrote:
> From: Jakub Narebski <jnareb@gmail.com>
> Subject: [PATCH 1/3] gitweb: Move 'lineno' id from link to row element in git_blame
> To: git@vger.kernel.org
> Cc: "Luben Tuikov" <ltuikov@yahoo.com>, "Jakub Narebski" <jnareb@gmail.com>
> Date: Tuesday, December 9, 2008, 2:46 PM
> Move l<line number> ID from <a> link element
> inside table row (inside
> cell element for column with line numbers), to encompassing
> <tr> table
> row element. It was done to make it easier to manipulate
> result HTML
> with DOM, and to be able write 'blame_incremental'
> view with the same,
> or nearly the same result.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Luben Tuikov <ltuikov@yahoo.com>
Luben
> ---
> For blame_incremental I need easy way to manipulate rows of
> blame
> table, to add information about blamed commits as it
> arrives.
>
> So there it is.
>
> gitweb/gitweb.perl | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 6eb370d..1b800f4 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -4645,7 +4645,7 @@ HTML
> if ($group_size) {
> $current_color = ++$current_color % $num_colors;
> }
> - print "<tr
> class=\"$rev_color[$current_color]\">\n";
> + print "<tr id=\"l$lineno\"
> class=\"$rev_color[$current_color]\">\n";
> if ($group_size) {
> print "<td
> class=\"sha1\"";
> print " title=\"". esc_html($author)
> . ", $date\"";
> @@ -4667,7 +4667,6 @@ HTML
> hash_base => $parent_commit);
> print "<td
> class=\"linenr\">";
> print $cgi->a({ -href =>
> "$blamed#l$orig_lineno",
> - -id => "l$lineno",
> -class => "linenr" },
> esc_html($lineno));
> print "</td>";
^ permalink raw reply
* Re: [PATCH 2/3] gitweb: Cache $parent_commit info in git_blame()
From: Luben Tuikov @ 2008-12-10 6:20 UTC (permalink / raw)
To: git, Jakub Narebski
In-Reply-To: <20081209224622.28106.89325.stgit@localhost.localdomain>
--- On Tue, 12/9/08, Jakub Narebski <jnareb@gmail.com> wrote:
> From: Jakub Narebski <jnareb@gmail.com>
> Subject: [PATCH 2/3] gitweb: Cache $parent_commit info in git_blame()
> To: git@vger.kernel.org
> Cc: "Luben Tuikov" <ltuikov@yahoo.com>, "Jakub Narebski" <jnareb@gmail.com>
> Date: Tuesday, December 9, 2008, 2:48 PM
> Luben Tuikov changed 'lineno' link from leading to
> commit which lead
> to current version of given block of lines, to leading to
> parent of
> this commit in 244a70e (Blame "linenr" link jumps
> to previous state at
> "orig_lineno"). This supposedly made data mining
> possible (or just
> better).
Before 244a70e, clicking on linenr links would display
the same commit id as displayed to the left, which is no
different than the block of lines displayed, thus data
mining was impossible, i.e. I had to manually (commands)
go back in history to see how this line or block of lines
developed and/or changed.
244a70e didn't make data mining perfect, just possible.
> This patch attempts to migitate issue a bit by caching
> $parent_commit
> info in %metainfo, which makes gitweb to call git-rev-parse
> only once
> per unique commit in blame output.
Have you tested this patch that it gives the same commit chain
as before it?
Luben
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> That is what I have noticed during browsing git_blame()
> code.
What?
> We can change it to even more effective implementation
> (like the ones
> proposed above in the commit message) later.
Where?
>
> Indenting is cause for artifically large diff
>
> gitweb/gitweb.perl | 16 +++++++++++-----
> 1 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 1b800f4..916396a 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -4657,11 +4657,17 @@ HTML
> esc_html($rev));
> print "</td>\n";
> }
> - open (my $dd, "-|", git_cmd(),
> "rev-parse", "$full_rev^")
> - or die_error(500, "Open git-rev-parse
> failed");
> - my $parent_commit = <$dd>;
> - close $dd;
> - chomp($parent_commit);
> + my $parent_commit;
> + if (!exists $meta->{'parent'}) {
> + open (my $dd, "-|", git_cmd(),
> "rev-parse", "$full_rev^")
> + or die_error(500, "Open git-rev-parse
> failed");
> + $parent_commit = <$dd>;
> + close $dd;
> + chomp($parent_commit);
> + $meta->{'parent'} = $parent_commit;
> + } else {
> + $parent_commit = $meta->{'parent'};
> + }
> my $blamed = href(action => 'blame',
> file_name =>
> $meta->{'filename'},
> hash_base => $parent_commit);
^ permalink raw reply
* Re: [PATCH 3/3] gitweb: A bit of code cleanup in git_blame()
From: Luben Tuikov @ 2008-12-10 6:24 UTC (permalink / raw)
To: git, Jakub Narebski
In-Reply-To: <20081209224814.28106.83387.stgit@localhost.localdomain>
--- On Tue, 12/9/08, Jakub Narebski <jnareb@gmail.com> wrote:
> From: Jakub Narebski <jnareb@gmail.com>
> Subject: [PATCH 3/3] gitweb: A bit of code cleanup in git_blame()
> To: git@vger.kernel.org
> Cc: "Luben Tuikov" <ltuikov@yahoo.com>, "Jakub Narebski" <jnareb@gmail.com>
> Date: Tuesday, December 9, 2008, 2:48 PM
> Among others:
> * move variable declaration closer to the place it is set
> and used,
> if possible,
> * uniquify and simplify coding style a bit, which includes
> removing
> unnecessary '()'.
> * check type only if $hash was defined, as otherwise from
> the way
> git_get_hash_by_path() is called (and works), we know
> that it is
> a blob,
> * use modern calling convention for git-blame,
> * remove unused variable,
> * don't use implicit variables ($_),
> * add some comments
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Luben Tuikov <ltuikov@yahoo.com>
Looks good.
> ---
> Not stricly necessary... but the code looked not very nice
>
> gitweb/gitweb.perl | 65
> ++++++++++++++++++++++++++++++----------------------
> 1 files changed, 37 insertions(+), 28 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 916396a..68aa3f8 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -4575,28 +4575,32 @@ sub git_tag {
> }
>
> sub git_blame {
> - my $fd;
> - my $ftype;
> -
> + # permissions
> gitweb_check_feature('blame')
> - or die_error(403, "Blame view not
> allowed");
> + or die_error(403, "Blame view not allowed");
>
> + # error checking
> die_error(400, "No file name given") unless
> $file_name;
> $hash_base ||= git_get_head_hash($project);
> - die_error(404, "Couldn't find base commit")
> unless ($hash_base);
> + die_error(404, "Couldn't find base commit")
> unless $hash_base;
> my %co = parse_commit($hash_base)
> or die_error(404, "Commit not found");
> if (!defined $hash) {
> $hash = git_get_hash_by_path($hash_base, $file_name,
> "blob")
> or die_error(404, "Error looking up file");
> + } else {
> + my $ftype = git_get_type($hash);
> + if ($ftype !~ "blob") {
> + die_error(400, "Object is not a blob");
> + }
> }
> - $ftype = git_get_type($hash);
> - if ($ftype !~ "blob") {
> - die_error(400, "Object is not a blob");
> - }
> - open ($fd, "-|", git_cmd(), "blame",
> '-p', '--',
> - $file_name, $hash_base)
> +
> + # run git-blame --porcelain
> + open my $fd, "-|", git_cmd(),
> "blame", '-p',
> + $hash_base, '--', $file_name
> or die_error(500, "Open git-blame failed");
> +
> + # page header
> git_header_html();
> my $formats_nav =
> $cgi->a({-href =>
> href(action=>"blob", -replay=>1)},
> @@ -4610,40 +4614,43 @@ sub git_blame {
> git_print_page_nav('','',
> $hash_base,$co{'tree'},$hash_base, $formats_nav);
> git_print_header_div('commit',
> esc_html($co{'title'}), $hash_base);
> git_print_page_path($file_name, $ftype, $hash_base);
> - my @rev_color = (qw(light2 dark2));
> +
> + # page body
> + my @rev_color = qw(light2 dark2);
> my $num_colors = scalar(@rev_color);
> my $current_color = 0;
> - my $last_rev;
> + my %metainfo = ();
> +
> print <<HTML;
> <div class="page_body">
> <table class="blame">
>
> <tr><th>Commit</th><th>Line</th><th>Data</th></tr>
> HTML
> - my %metainfo = ();
> - while (1) {
> - $_ = <$fd>;
> - last unless defined $_;
> + LINE:
> + while (my $line = <$fd>) {
> + chomp $line;
> + # the header: <SHA-1> <src lineno> <dst
> lineno> [<lines in group>]
> + # no <lines in group> for subsequent lines in
> group of lines
> my ($full_rev, $orig_lineno, $lineno, $group_size) =
> - /^([0-9a-f]{40}) (\d+) (\d+)(?:
> (\d+))?$/;
> + ($line =~ /^([0-9a-f]{40}) (\d+) (\d+)(?:
> (\d+))?$/);
> if (!exists $metainfo{$full_rev}) {
> $metainfo{$full_rev} = {};
> }
> my $meta = $metainfo{$full_rev};
> - while (<$fd>) {
> - last if (s/^\t//);
> - if (/^(\S+) (.*)$/) {
> + while (my $data = <$fd>) {
> + chomp $data;
> + last if ($data =~ s/^\t//); # contents of line
> + if ($data =~ /^(\S+) (.*)$/) {
> $meta->{$1} = $2;
> }
> }
> - my $data = $_;
> - chomp $data;
> - my $rev = substr($full_rev, 0, 8);
> + my $short_rev = substr($full_rev, 0, 8);
> my $author = $meta->{'author'};
> - my %date = parse_date($meta->{'author-time'},
> - $meta->{'author-tz'});
> + my %date =
> + parse_date($meta->{'author-time'},
> $meta->{'author-tz'});
> my $date = $date{'iso-tz'};
> if ($group_size) {
> - $current_color = ++$current_color % $num_colors;
> + $current_color = ($current_color + 1) % $num_colors;
> }
> print "<tr id=\"l$lineno\"
> class=\"$rev_color[$current_color]\">\n";
> if ($group_size) {
> @@ -4654,7 +4661,7 @@ HTML
> print $cgi->a({-href =>
> href(action=>"commit",
> hash=>$full_rev,
>
> file_name=>$file_name)},
> - esc_html($rev));
> + esc_html($short_rev));
> print "</td>\n";
> }
> my $parent_commit;
> @@ -4683,6 +4690,8 @@ HTML
> print "</div>";
> close $fd
> or print "Reading blob failed\n";
> +
> + # page footer
> git_footer_html();
> }
^ permalink raw reply
* Re: [PATCH] make sure packs to be replaced are closed beforehand
From: Johannes Sixt @ 2008-12-10 7:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812091414030.14328@xanadu.home>
Nicolas Pitre schrieb:
> Especially on Windows where an opened file cannot be replaced, make
> sure pack-objects always close packs it is about to replace. Even on
> non Windows systems, this could save potential bad results if ever
> objects were to be read from the new pack file using offset from the old
> index.
>
> This should fix t5303 on Windows.
...
> OK, here it is at last. Please confirm it works on Windows before Junio
> merges it.
I can confirm that this patch fixes t5303 on Windows (MinGW).
-- Hannes
^ permalink raw reply
* Re: git fsck segmentation fault
From: Martin Koegler @ 2008-12-10 7:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Simon Hausmann, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812091408560.14328@xanadu.home>
Maybe something like this could help:
>From 32be177cbb0825fc019200b172f3d79117b28140 Mon Sep 17 00:00:00 2001
From: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Date: Wed, 10 Dec 2008 08:42:08 +0100
Subject: [PATCH] fsck: use fewer stack
This patch moves the state while traversing the tree
from the stack to the heap.
Not-really-tested-by: Martin Koegler
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
builtin-fsck.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index afded5e..8184699 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -36,6 +36,9 @@ static int verbose;
#define DIRENT_SORT_HINT(de) ((de)->d_ino)
#endif
+static int objectstack_nr, objectstack_alloc;
+struct object **objectstack;
+
static void objreport(struct object *obj, const char *severity,
const char *err, va_list params)
{
@@ -66,9 +69,7 @@ static int fsck_error_func(struct object *obj, int type, const char *err, ...)
static int mark_object(struct object *obj, int type, void *data)
{
- struct tree *tree = NULL;
struct object *parent = data;
- int result;
if (!obj) {
printf("broken link from %7s %s\n",
@@ -95,6 +96,15 @@ static int mark_object(struct object *obj, int type, void *data)
}
return 1;
}
+ ALLOC_GROW(objectstack, objectstack_nr + 1, objectstack_alloc);
+ objectstack[objectstack_nr++] = obj;
+ return 0;
+}
+
+static int mark_child_object(struct object *obj)
+{
+ struct tree *tree = NULL;
+ int result;
if (obj->type == OBJ_TREE) {
obj->parsed = 0;
@@ -116,6 +126,11 @@ static int mark_object(struct object *obj, int type, void *data)
static void mark_object_reachable(struct object *obj)
{
mark_object(obj, OBJ_ANY, 0);
+ while (objectstack_nr > 0) {
+ struct object *obj = objectstack[--objectstack_nr];
+ if (mark_child_object(obj) < 0)
+ break;
+ }
}
static int mark_used(struct object *obj, int type, void *data)
--
1.6.1.rc2.283.g32be1
^ permalink raw reply related
* Re: [PATCH] make sure packs to be replaced are closed beforehand
From: Junio C Hamano @ 2008-12-10 8:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nicolas Pitre, Alex Riesen, Git Mailing List
In-Reply-To: <493F71B7.60804@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Nicolas Pitre schrieb:
>> Especially on Windows where an opened file cannot be replaced, make
>> sure pack-objects always close packs it is about to replace. Even on
>> non Windows systems, this could save potential bad results if ever
>> objects were to be read from the new pack file using offset from the old
>> index.
>>
>> This should fix t5303 on Windows.
> ...
>> OK, here it is at last. Please confirm it works on Windows before Junio
>> merges it.
>
> I can confirm that this patch fixes t5303 on Windows (MinGW).
Thanks; it is a bit too late for tonight, but it will appear in tomorrow's
'master'.
^ permalink raw reply
* Re: [PATCH 2/2] diff: respect textconv in rewrite diffs
From: Junio C Hamano @ 2008-12-10 8:34 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081209081321.GA19707@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Currently we just skip rewrite diffs for binary files; this patch makes
> an exception for files which will be textconv'd, and actually performs
> the textconv before generating the diff.
>
> Conceptually, rewrite diffs should be in the exact same format as the a
> non-rewrite diff, except that we refuse to share any context. Thus it
> makes very little sense for "git diff" to show a textconv'd diff, but
> for "git diff -B" to show "Binary files differ".
Makes sense.
> +cat >dump <<'EOF'
> +#!/bin/sh
> +perl -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' < "$1"
> +EOF
I'll squash in a change to make this part use $SHELL_PATH for
consistency. Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] diff: fix handling of binary rewrite diffs
From: Junio C Hamano @ 2008-12-10 8:34 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081209081227.GA19626@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Instead, if we have binary files, then let's just skip emit_rewrite_diff
> altogether. We will already have shown the "dissimilarity index" line,
> so it is really about the diff contents. If binary diffs are turned off,
> the "Binary files a/file and b/file differ" message should be the same
> in either case. If we do have binary patches turned on, there isn't much
> point in making a less-efficient binary patch that does a total rewrite;
> no human is going to read it, and since binary patches don't apply with
> any fuzz anyway, the result of application should be the same.
Makes sense.
> diff.c | 4 ++-
> t/t4031-diff-rewrite-binary.sh | 42 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 45 insertions(+), 1 deletions(-)
> create mode 100755 t/t4031-diff-rewrite-binary.sh
>
> diff --git a/diff.c b/diff.c
> index f644947..ea958a2 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1376,7 +1376,9 @@ static void builtin_diff(const char *name_a,
> */
> if ((one->mode ^ two->mode) & S_IFMT)
> goto free_ab_and_return;
> - if (complete_rewrite) {
> + if (complete_rewrite &&
> + !diff_filespec_is_binary(one) &&
> + !diff_filespec_is_binary(two)) {
> emit_rewrite_diff(name_a, name_b, one, two, o);
> o->found_changes = 1;
> goto free_ab_and_return;
And looks correct.
> diff --git a/t/t4031-diff-rewrite-binary.sh b/t/t4031-diff-rewrite-binary.sh
> new file mode 100755
> index 0000000..4b522f7
> --- /dev/null
> +++ b/t/t4031-diff-rewrite-binary.sh
> @@ -0,0 +1,42 @@
> +#!/bin/sh
> +
> +test_description='rewrite diff on binary file'
> +
> +. ./test-lib.sh
> +
> +# We must be large enough to meet the MINIMUM_BREAK_SIZE
> +# requirement.
> +make_file() {
> + for i in 1 2 3 4 5 6 7 8 9 10; do
> + for j in 1 2 3 4 5 6 7 9 10; do
> + for k in 1 2 3 4 5; do
> + printf "$1\n"
> + done
> + done
> + done >file
> +}
> +
> +test_expect_success 'create binary file with changes' '
> + make_file "\\0" &&
> + git add file &&
> + make_file "\\01"
> +'
Hmm... "1 2 3 4 5 6 7 9 10"?
^ permalink raw reply
* Re: [PATCH 3/3] gitweb: A bit of code cleanup in git_blame()
From: Junio C Hamano @ 2008-12-10 8:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ghn8jv$hg9$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Jakub Narebski wrote:
>
> I'm sorry, there should be
>
> + my $ftype = "blob";
>> if (!defined $hash) {
>> $hash = git_get_hash_by_path($hash_base, $file_name, "blob")
>> or die_error(404, "Error looking up file");
>> + } else {
>> + $ftype = git_get_type($hash);
>> + if ($ftype !~ "blob") {
>> + die_error(400, "Object is not a blob");
>> + }
I will squash in the following and queue [1/3] and [3/3] to 'pu', as there
seem to be a few comments on [2/3] that look worth addressing.
gitweb/gitweb.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git c/gitweb/gitweb.perl w/gitweb/gitweb.perl
index d491a1d..ccbf5d4 100755
--- c/gitweb/gitweb.perl
+++ w/gitweb/gitweb.perl
@@ -4585,11 +4585,12 @@ sub git_blame {
die_error(404, "Couldn't find base commit") unless $hash_base;
my %co = parse_commit($hash_base)
or die_error(404, "Commit not found");
+ my $ftype = "blob";
if (!defined $hash) {
$hash = git_get_hash_by_path($hash_base, $file_name, "blob")
or die_error(404, "Error looking up file");
} else {
- my $ftype = git_get_type($hash);
+ $ftype = git_get_type($hash);
if ($ftype !~ "blob") {
die_error(400, "Object is not a blob");
}
@@ -4637,7 +4638,8 @@ HTML
$metainfo{$full_rev} = {};
}
my $meta = $metainfo{$full_rev};
- while (my $data = <$fd>) {
+ my $data;
+ while ($data = <$fd>) {
chomp $data;
last if ($data =~ s/^\t//); # contents of line
if ($data =~ /^(\S+) (.*)$/) {
^ permalink raw reply related
* [PATCH] git-gui: Fixed typos in Swedish translation.
From: Peter Krefting @ 2008-12-10 8:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0812091623590.31023@ds9.cixit.se>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 189 bytes --]
> Patch to the Swedish translation is attached gzipped.
Thanks for applying it. I found two typos, which are corrected by the
attached patch.
--
\\// Peter - http://www.softwolves.pp.se/
[-- Attachment #2: [PATCH] git-gui: Fixed typos in Swedish translation. --]
[-- Type: APPLICATION/octet-stream, Size: 757 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] diff: respect textconv in rewrite diffs
From: Jeff King @ 2008-12-10 9:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3agw2zu5.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 10, 2008 at 12:34:26AM -0800, Junio C Hamano wrote:
> > +cat >dump <<'EOF'
> > +#!/bin/sh
> > +perl -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' < "$1"
> > +EOF
>
> I'll squash in a change to make this part use $SHELL_PATH for
> consistency. Thanks.
It was cut-and-paste from t4030, so if we care, it might be worth
changing there, too (and naming it "dump" instead of "hexdump", because
it actually dumps in decimal :) ).
But more importantly, the fixup you just pushed seems to have an extra
">dump":
> +{
> + echo "#!$SHELL_PATH"
> + cat >dump <<'EOF'
> +perl -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' < "$1"
> +EOF
> +} >dump
> +chmod +x dump
-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