* Re: [PATCH] Make cvsexportcommit work with filenames containing spaces.
From: Junio C Hamano @ 2006-09-29 6:37 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200609290128.56217.robin.rosenberg@dewire.com>
Please do not do more than one patch per e-mail; I'll have to
save the attachment in separate files and manually make commits,
which is more work.
The build procedure for the release to build rpms runs testsuite
as part of it, so I need to think a bit how to proceed with this
patch. Leaving the test failing on FC5 means I won't be able to
cut binary releases. Checking early in the test script to see
if "patch" can grok a diff for a file with whitespaces, and
skipping the whitespace test if we have a bad "patch", seems to
the best workaround.
BTW, the addition of TAB to the patch tail is done by "git diff"
automatically for files with whitespace in them in the proposed
updates version in "pu" (and it is done conditionally only for
files whose names have whitespace), so I think your fix will
become redundant when it graduates to "master".
^ permalink raw reply
* Re: [PATCH 1/3] diff --stat: allow custom diffstat output width.
From: Linus Torvalds @ 2006-09-29 6:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609282252430.3952@g5.osdl.org>
On Thu, 28 Sep 2006, Linus Torvalds wrote:
>
> because the only reason strtoul() warns now is that C type-rules don't
> allow the (obviously safe - but pointers migth have strange
> representations) conversion of "char **" into "const char **", even though
> "char *" can be converted into "const char *".
I phrased that badly.
IF C pointer conversion allowed implicit addition of "const" past the
top-most level, ANSI C would have just done "strtoul()" as
unsigned long strtoul(const char *n, const char **p, int);
ie they could just have added the "const" not just to the first argument,
and legact programs (without const) would still have worked fine.
But _because_ that's not how C type rules work, we have the current
situation where the first argument is a "const char *", and the second
argument _logically_ should be a pointer to such an entity, but because
that would have caused bogus warnings for any code that just used a
regular "char **" without any const at all, that wasn't an option.
So that explains why ANSI C has insane imbalances like this. It's easy to
add a "const" to a _first-level_ pointer to say "we allow both const and
regular pointers to this thing", but sadly you can't do it for a pointer
to such a pointer.
Linus
^ permalink raw reply
* Re: Fix approxidate() to understand more extended numbers
From: Junio C Hamano @ 2006-09-29 6:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Morten Welinder, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0609282300190.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 28 Sep 2006, Morten Welinder wrote:
>>
>> Just don't hack at 12am or 12pm.
>
> I think 12pm is correct, but 12am probably isn't (12am should _subtract_
> 12, while 12pm does _not_ add 12).
But you have "if (hour > 0 && hour < 12)" in both am and pm so
assignment to tm would not trigger...
> That said, I have a rice cooker that avoids the problem by saying "0:10 PM"
> for ten minutes past midday ;)
You eat rice?
> Of course, all sane and civilized countries just use 24-hour format
> anyway.
You are referring to the US, but neither is Japan sane nor
civilized ;-).
^ permalink raw reply
* Re: [PATCH 1/3] diff --stat: allow custom diffstat output width.
From: Junio C Hamano @ 2006-09-29 6:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609282252430.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 28 Sep 2006, Junio C Hamano wrote:
>>
>> This is simply too clever; -pedantic does not like assignment of
>> arg to end (constness -- and strtoul takes pointer to non-const
>> char *, so making the type of end const char * is not an answer
>> either).
>
> The _code_ really is right. The problem is "strtoul()" interfaces and a
> C typing oddity.
Yes, the code is right (not only because you wrote it ;-) and
not just right but it is crystal clear to humans what is going
on and why the final "if (*end)" is all that is needed without
any "return 0" in the middle.
> At that point, the cast is probably simpler,...
... which I ended up doing anyway.
Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: hash_base and hash are now context sensitive
From: Junio C Hamano @ 2006-09-29 6:06 UTC (permalink / raw)
To: ltuikov; +Cc: Jakub Narebski, git
In-Reply-To: <20060928185232.96094.qmail@web31802.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
>> > > Agreed, we should always refer to the commit-ish, for obvious
>> > > reasons.
>> > >
>> > > This patch doesn't make this decision though. It simply
>> > > sets hash_base to HEAD if not defined.
>> > >
>> > > Now, since "git-ls-tree" works on both commit-ish and
>> > > tree-ish, we are ok.
>> >
>> > I think so, too. Jakub?
>>
>> Status? I see Jakub hasn't objected, and it is really important
>> for us to be able to link to "latest" binary blob -- for example
>> a PDF spec file.
>
> Junio,
>
> What are the objections to this patch?
No objections from me --- rather lack of objections from Jakub ;-)
But the fragments do not appear to apply anymore.
@@ -1625,7 +1625,7 @@ sub git_print_tree_entry {
"history");
}
print " | " .
- $cgi->a({-href => href(action=>"blob_plain", hash_base=>"HEAD",
+ $cgi->a({-href => href(action=>"blob_plain", hash_base=>$hash_base,
file_name=>"$basedir$t->{'name'}")},
"raw");
print "</td>\n";
There is no call to create blob_plain link with hash_base
hardcoded to "HEAD" in git-print-tree-entry.
Care to re-spin?
^ permalink raw reply
* Re: Fix approxidate() to understand more extended numbers
From: Linus Torvalds @ 2006-09-29 6:03 UTC (permalink / raw)
To: Morten Welinder; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <118833cc0609281712u2ce01bc5r8f3e97ae9c9a749a@mail.gmail.com>
On Thu, 28 Sep 2006, Morten Welinder wrote:
>
> Just don't hack at 12am or 12pm.
I think 12pm is correct, but 12am probably isn't (12am should _subtract_
12, while 12pm does _not_ add 12).
That said, I have a rice cooker that avoids the problem by saying "0:10 PM"
for ten minutes past midday ;)
Of course, all sane and civilized countries just use 24-hour format
anyway. "Military time" my *ss.
Some day the US will turn metric and 24-hour-format. If the sun doesn't
turn into a red giant first, that is.
Linus
^ permalink raw reply
* Re: [PATCH 1/3] diff --stat: allow custom diffstat output width.
From: Linus Torvalds @ 2006-09-29 5:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6xvp7jm.fsf@assigned-by-dhcp.cox.net>
On Thu, 28 Sep 2006, Junio C Hamano wrote:
>
> This is simply too clever; -pedantic does not like assignment of
> arg to end (constness -- and strtoul takes pointer to non-const
> char *, so making the type of end const char * is not an answer
> either).
The _code_ really is right. The problem is "strtoul()" interfaces and a
C typing oddity.
> And I do not like casting constness away: end = (char *) arg.
You could fix it by doing something like this:
static inline unsigned long sane_strtoul(const char *n,
const char **p,
int base)
{
char *end;
unsigned long res;
res = strtoul(n, &end, base);
*p = end;
return res;
}
because the only reason strtoul() warns now is that C type-rules don't
allow the (obviously safe - but pointers migth have strange
representations) conversion of "char **" into "const char **", even though
"char *" can be converted into "const char *".
At that point, the cast is probably simpler, but the above should be
strictly correct pedantic ANSI C.
I didn't even try it, though.
Linus
^ permalink raw reply
* Re: [PATCH 1/3] diff --stat: allow custom diffstat output width.
From: Junio C Hamano @ 2006-09-29 5:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609281458420.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I could have made it a more obvious "stupid" parser, I just think it's
> better to do it this way.
>
> + else if (!strncmp(arg, "--stat", 6)) {
> + char *end;
> + int width = options->stat_width;
> + int name_width = options->stat_name_width;
> + arg += 6;
> + end = arg;
> +
> + switch (*arg) {
> + case '-':
> + if (!strncmp(arg, "-width=", 7))
> + width = strtoul(arg + 7, &end, 10);
> + else if (!strncmp(arg, "-name-width=", 12))
> + name_width = strtoul(arg + 12, &end, 10);
> + break;
> +
> + case '=':
> + width = strtoul(arg+1, &end, 10);
> + if (*end == ',')
> + name_width = strtoul(end+1, &end, 10);
> + }
> +
> + /* Important! This checks all the error cases! */
> + if (*end)
> + return 0;
> options->output_format |= DIFF_FORMAT_DIFFSTAT;
> + options->stat_name_width = name_width;
> + options->stat_width = width;
> }
This is simply too clever; -pedantic does not like assignment of
arg to end (constness -- and strtoul takes pointer to non-const
char *, so making the type of end const char * is not an answer
either).
And I do not like casting constness away: end = (char *) arg.
Hmmmm.
^ permalink raw reply
* Re: [PATCH] --stat: ensure at least one '-' for deletions, and one '+' for additions
From: Johannes Schindelin @ 2006-09-29 4:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd59fquc5.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 28 Sep 2006, Junio C Hamano wrote:
> Another way is what I suggested earlier -- if the width is odd, drop one
> to avoid this problem altogether. That would also be acceptable and
> probably be more consistent.
I see that you care deeply about the 7 column example. In that case, yes,
I would rather have columns be rounded down to the next even number.
I care more about the consistency: if there are changes, I want to see
them, and it should be linear: the more changes, the more plusses or
minusses.
Ciao,
Dscho
P.S.: here's a patch on top of my last one:
-- snip --
[PATCH] force even diffstat width
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
diff.c | 3 ++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index 53c30bd..2a898e6 100644
--- a/diff.c
+++ b/diff.c
@@ -729,6 +729,9 @@ static void show_stats(struct diffstat_t
else
width = max_change;
+ /* force width to be even */
+ width &= ~1;
+
for (i = 0; i < data->nr; i++) {
const char *prefix = "";
char *name = data->files[i]->name;
--
1.4.2.1.g1a99e1-dirty
^ permalink raw reply related
* Re: [PATCH] fetch: Add output for the not fast forward case
From: Junio C Hamano @ 2006-09-29 2:29 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <873babbptl.fsf@gmail.com>
Santi Béjar <sbejar@gmail.com> writes:
> This patch follows the notation of the other mail, but for the
> not-fast-forward case I think it makes more sense to use the '...'
> notation.
Again, justification for three-dots not two as others is needed
in the commit log part, not the commentary part.
I tend to agree with you that A...B is nice in this case, _if_
we use A..B for others. Using A..B for others (I am guessing
that you are doing this for Cut & Paste reasons to grab the
whole range as one word) means that we assume users are a lot
more likely to be interested in grabbing A..B as a range than
grabbing only A or B as a point.
I will not discuss if that assumption is correct here, but if we
assume it is, using A...B makes a lot of sense for this case.
After grabbing A..B in other cases, the user can give that to
"git log" to see what the changes between old and new are. In
this non-fast-forward case, if we used three-dots A...B to talk
about the two heads, the user can give it to "git log" to see
how the two non-fast-forward heads have diverged.
So the choice of .. and ... are internally consistent and very
sensible.
The question is if people more often want to grab both as a
range than they want to grab either end point alone. I am
inclined to think your assumption is correct, but am not
absolutely sure.
^ permalink raw reply
* Re: [PATCH] gitweb: Add snapshot to log; remove redundant commit from log
From: Junio C Hamano @ 2006-09-29 2:29 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20060928235050.63085.qmail@web31808.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Adding "snapshot" without removing redundant "commit" makes
> it too messy as the log gets out of visual alignment.
>
> I'm ambivalent whether this goes in or not.
I admit I was who suggested "we might want to", but I agree this
is going a bit too far.
^ permalink raw reply
* Re: [PATCH] Use "hash1..hash2" instead of "from hash1 to hash2"
From: Junio C Hamano @ 2006-09-29 2:28 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <877iznbq0v.fsf@gmail.com>
This kind of "appearance only" change needs better
justification. Not that I am saying "from .. to" is better for
such and such reasons, but that's how it's been, so if you are
proposing to change it, you need to defend why it would help
users (otherwise I would get hate mails that say "why did you
merge it -- it broke my work habit in such and such way").
You may be doing this for brevity. In that case, it could
also be worth shortening them to n unique digits; do we have a
command to get "here is the SHA-1; give me its unique
abbreviation at least n letters long but make it longer as
needed to keep it unique"?
You may be doing this to help Cut & Paste. Using A..B without
spaces in between makes it easy to grab both at the same time as
a range to give them to "git log". At the same time it makes it
harder to pick only A or B, so this is two-edged.
^ permalink raw reply
* Re: [PATCH] --stat: ensure at least one '-' for deletions, and one '+' for additions
From: Junio C Hamano @ 2006-09-29 2:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609281942360.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> However, I would argue it's actually an improvement. If you have as many
> additions as deletions, there should be an equal number of '-' and '+'.
That's one way to look at it.
Now how would you explain that a file that had 5 adds and 5
deletes gets three pluses and three minuses while another file
that had 10 adds and no delets gets seven pluses?
Compute total and add, make del=total-add:
foo | 10 ++++---
bar | 10 +++++++
Compute add and del independently:
foo | 10 +++---
bar | 10 +++++++
> After all, the integer number of symbols is just an approximation anyway.
Yes, and my guess is that the graph is usually much wider than 7
columns as depicted above, so 3 vs 4 inconsistency in the former
is less noticeable than 6 vs 7 inconsistency in the latter to
the eye. If we have to make a compromise, I think getting the
lines for the files that have the same number of changes to line
up at the right end would be more important.
Another way is what I suggested earlier -- if the width is odd,
drop one to avoid this problem altogether. That would also be
acceptable and probably be more consistent.
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-29 2:28 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git
In-Reply-To: <20060929014430.44203.qmail@web51006.mail.yahoo.com>
Matthew L Foster <mfoster167@yahoo.com> writes:
> Ok, I was wondering about that. In your example above the
> internally unnecessary timestamp will be from Linus' private
> repo, not master.kernel.org's?
Yes, and it is stronger than that. If somebody did a sata
patch, sent that to Jeff over e-mail, and if the patch was
accepted, Jeff will make a commit in his private repository,
recording local time on his machine. Later Linus may pull from
Jeff and the commit object is transferred during that.
To Linus, the time he first saw the commit was the time he
pulled from Jeff, so being able to tell when it came into his
repository may help him if he pulled from other people too and
then suddenly realizes his sata disk does not respond at all.
He COULD say "it was working yesterday, I pulled from Jeff 3
hours ago, and then David 2 hours ago, I did not do my own
development during that time. Did the breakage come when I
pulled from Jeff or when I pulled from David?" ref-log would
let him do something like:
git checkout -b trythis master@{4.hours.ago}
to make sure the state before he pulled from Jeff was a working
state and then still on the trythis branch he cuold do
git reset --hard master@{2.hours.30.minutes.ago}
to see if the state after he pulled from Jeff was broken.
Side note: in reality he does not have to care. He can
just bisect it without using any of his "pull boundary"
time.
So that was discussion about the time Linus first saw the
commit. What about us, general public? Until Linus pushes out
the merge result, we would not see it. Anyway, eventually he
will push his tip of the branch out to kernel.org and rsync will
mirror to public git:// and gitweb machines.
What's the local time the general public sees the commit for the
first time? It's (forgetting for now the rsync mirroring delay)
the time Linus pushed the tip of the branch out. Along with all
other hundreds of commits he acquired since the last time he
pushed his tree out.
It is sometimes useful to know when a particular commit has
become available to the general public. I do not think anybody
is denying it.
But it is a completely separate issue if it is useful to label
the commits that happened to be pushed out together at the same
time with the same timestamp on the gitweb short-log page (or
short-log corner on the summary page). Most of the time you
will see commits pushed out by the same push operation and
having exactly the same timestamp. That's not very useful way
to present the information.
Side note: some commits arrive kernel.org machine
earlier than others because Linus does not have infinite
bandwidth to kernel.org, but these hundreds of commits
become visible to the general public exactly the same
time, because we send them and as the last operation we
update the tip of the branch. So you cannot even say
"record the time down to the second they arrived the
kernel.org repository" -- until the branch tip is
updated the general public cannot see them so the
arrival time (mtime of .git/objects/??/???...?? files)
does not even matter.
If somebody feels strongly about it, I would suggest adding that
information on the commit page of gitweb, where the program
needs to deal with only one commit. That would help somebody
who is interested in _one_ particular commit and wants to know
when it has become available to the general public.
-
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-29 1:44 UTC (permalink / raw)
To: Theodore Tso; +Cc: Linus Torvalds, Rogan Dawes, git
In-Reply-To: <20060929002748.GA11055@thunk.org>
--- Theodore Tso <tytso@mit.edu> wrote:
> Git mirroring takes place using the same pushing and pulling that are
> used with multiple repositories. That's why if Linus does a huge
> amount of work over the period of a day or two in his private
> repository, and then publishes it master.kernel.org, the "local" time
> on master.kernel.org will be the time when they are pushed to
> master.kernel.org, because it's done via the same operation as any
> other repository push or pull.
>
> That's what everyone has been trying to tell you for this entire
> thread....
Ok, I was wondering about that. In your example above the internally unnecessary timestamp will be
from Linus' private repo, not master.kernel.org's? Even now knowing replication = merge/push/pull
I still think it worthwile for local commit time to be effiently tracked locally and/or if already
available in the local ref-log used by things like gitweb.cgi if feasible but I might be the only
one that cares this much about time. Gitweb.cgi currently relies at least display/visually on
those internally unnecessary and potentially misleading timestamps...
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH 1/3] diff --stat: allow custom diffstat output width.
From: Junio C Hamano @ 2006-09-29 1:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609281458420.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> You should probably check the "width" and "name_width" values for sanity.
The output code forces (well, at least tries to force) some
sanity into these values when they are not, so probably we do
not need it. If we want, we could check something like:
if (name_width < 10 || width - name_width < 15)
die("at least 10 for name, and 15+name for width please");
The number 10 is totally arbitrary; among the total area that is
given by width, after subtracting name_width, 10 columns are
taken by left and right end space, vertical bar and numbers, so
the above gives at least 5 columns to draw the graph.
^ permalink raw reply
* Re: git and time
From: Theodore Tso @ 2006-09-29 0:27 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Linus Torvalds, Rogan Dawes, git
In-Reply-To: <20060928191816.76466.qmail@web51014.mail.yahoo.com>
On Thu, Sep 28, 2006 at 12:18:15PM -0700, Matthew L Foster wrote:
> --- Linus Torvalds <torvalds@osdl.org> wrote:
>
> > - it means that the -same- exact project, when looked at frm two
> > different sites that mirror it, have totally different times. In other
> > words, the times have become pointless for something like gitweb.
>
> Mirrored git repos probably should use the same timestamp, e.g. the
> "master" or "private" git server's local time. Replicated repos have
> a delay compared to when you made changes in your private repo, that
> is ok, replication is not what makes commit order inconsistent with
> time, it's the act of pulling/merging from a server with
> misconfigured time and gitweb.cgi trusting "creation time", right?
> Or is replication the same thing as merging/pulling?
Git mirroring takes place using the same pushing and pulling that are
used with multiple repositories. That's why if Linus does a huge
amount of work over the period of a day or two in his private
repository, and then publishes it master.kernel.org, the "local" time
on master.kernel.org will be the time when they are pushed to
master.kernel.org, because it's done via the same operation as any
other repository push or pull.
That's what everyone has been trying to tell you for this entire
thread....
- Ted
^ permalink raw reply
* [PATCH] gitweb: History: blob and tree are first, then commitdiff, etc
From: Luben Tuikov @ 2006-09-29 0:21 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 454 bytes --]
Reorder link display in history to be consistent with other
list displays: log, shortlog, etc. We now display:
blob | commitdiff
blob | commitdiff | diff_to_current
and
tree | commitdiff
Instead of the old history format where "blob" and "tree"
are between "commitdiff" and "diff_to_current" if present/
applicable.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
[-- Attachment #2: 1908141687-p2.txt --]
[-- Type: text/plain, Size: 819 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c0f7dff..f175237 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2071,8 +2071,8 @@ sub git_history_body {
href(action=>"commit", hash=>$commit), $ref);
print "</td>\n" .
"<td class=\"link\">" .
- $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") . " | " .
- $cgi->a({-href => href(action=>$ftype, hash_base=>$commit, file_name=>$file_name)}, $ftype);
+ $cgi->a({-href => href(action=>$ftype, hash_base=>$commit, file_name=>$file_name)}, $ftype) . " | " .
+ $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff");
if ($ftype eq 'blob') {
my $blob_current = git_get_hash_by_path($hash_base, $file_name);
--
1.4.2.1.g8492a
^ permalink raw reply related
* [PATCH] gitweb: Remove redundant "commit" from history
From: Luben Tuikov @ 2006-09-29 0:20 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 296 bytes --]
Remove redundant "commit" from history -- it can be had
by clicking on the title of the commit. This commit
makes visualization consistent with shortlog, log, etc.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
[-- Attachment #2: 1207600725-p1.txt --]
[-- Type: text/plain, Size: 613 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index fdbdb82..c0f7dff 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2071,7 +2071,6 @@ sub git_history_body {
href(action=>"commit", hash=>$commit), $ref);
print "</td>\n" .
"<td class=\"link\">" .
- $cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") . " | " .
$cgi->a({-href => href(action=>$ftype, hash_base=>$commit, file_name=>$file_name)}, $ftype);
--
1.4.2.1.g8492a
^ permalink raw reply related
* Re: Fix approxidate() to understand more extended numbers
From: Morten Welinder @ 2006-09-29 0:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0609281212380.3952@g5.osdl.org>
Just don't hack at 12am or 12pm.
M.
^ permalink raw reply
* [PATCH v2] http/ftp: optionally ask curl to not use EPSV command
From: Sasha Khapyorsky @ 2006-09-29 0:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060929000754.GK10617@sashak.voltaire.com>
If http.noEPSV config variable is defined and true, or if
GIT_CURL_FTP_NO_EPSV environment variable is defined, disable using
of EPSV ftp command (PASV will be used instead). This is helpful with
some "poor" ftp servers which does not support EPSV mode.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
---
Documentation/config.txt | 6 ++++++
git-clone.sh | 4 ++++
git-fetch.sh | 6 +++++-
git-ls-remote.sh | 4 ++++
http.c | 12 ++++++++++++
5 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 98c1f3e..84e3891 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -202,6 +202,12 @@ http.lowSpeedLimit, http.lowSpeedTime::
Can be overridden by the 'GIT_HTTP_LOW_SPEED_LIMIT' and
'GIT_HTTP_LOW_SPEED_TIME' environment variables.
+http.noEPSV::
+ A boolean which disables using of EPSV ftp command by curl.
+ This can helpful with some "poor" ftp servers which doesn't
+ support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'
+ environment variable. Default is false (curl will use EPSV).
+
i18n.commitEncoding::
Character encoding the commit messages are stored in; git itself
does not care per se, but this information is necessary e.g. when
diff --git a/git-clone.sh b/git-clone.sh
index e1b3bf3..3998c55 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -31,6 +31,10 @@ clone_dumb_http () {
cd "$2" &&
clone_tmp="$GIT_DIR/clone-tmp" &&
mkdir -p "$clone_tmp" || exit 1
+ if [ -n "$GIT_CURL_FTP_NO_EPSV" -o \
+ "`git-repo-config --bool http.noEPSV`" = true ]; then
+ curl_extra_args="${curl_extra_args} --disable-epsv"
+ fi
http_fetch "$1/info/refs" "$clone_tmp/refs" || {
echo >&2 "Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?"
diff --git a/git-fetch.sh b/git-fetch.sh
index 50ad101..04d4dbb 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -289,6 +289,10 @@ fetch_main () {
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
+ if [ -n "$GIT_CURL_FTP_NO_EPSV" -o \
+ "`git-repo-config --bool http.noEPSV`" = true ]; then
+ noepsv_opt="--disable-epsv"
+ fi
max_depth=5
depth=0
head="ref: $remote_name"
@@ -300,7 +304,7 @@ fetch_main () {
$u =~ s{([^-a-zA-Z0-9/.])}{sprintf"%%%02x",ord($1)}eg;
print "$u";
' "$head")
- head=$(curl -nsfL $curl_extra_args "$remote/$remote_name_quoted")
+ head=$(curl -nsfL $curl_extra_args $noepsv_opt "$remote/$remote_name_quoted")
depth=$( expr \( $depth + 1 \) )
done
expr "z$head" : "z$_x40\$" >/dev/null ||
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index 2c0b521..0f88953 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -53,6 +53,10 @@ http://* | https://* | ftp://* )
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
+ if [ -n "$GIT_CURL_FTP_NO_EPSV" -o \
+ "`git-repo-config --bool http.noEPSV`" = true ]; then
+ curl_extra_args="${curl_extra_args} --disable-epsv"
+ fi
curl -nsf $curl_extra_args --header "Pragma: no-cache" "$peek_repo/info/refs" ||
echo "failed slurping"
;;
diff --git a/http.c b/http.c
index 6c1937b..576740f 100644
--- a/http.c
+++ b/http.c
@@ -23,6 +23,7 @@ #endif
char *ssl_cainfo = NULL;
long curl_low_speed_limit = -1;
long curl_low_speed_time = -1;
+int curl_ftp_no_epsv = 0;
struct curl_slist *pragma_header;
@@ -155,6 +156,11 @@ #endif
return 0;
}
+ if (!strcmp("http.noepsv", var)) {
+ curl_ftp_no_epsv = git_config_bool(var, value);
+ return 0;
+ }
+
/* Fall back on the default ones */
return git_default_config(var, value);
}
@@ -196,6 +202,9 @@ #endif
curl_easy_setopt(result, CURLOPT_USERAGENT, GIT_USER_AGENT);
+ if (curl_ftp_no_epsv)
+ curl_easy_setopt(result, CURLOPT_FTP_USE_EPSV, 0);
+
return result;
}
@@ -251,6 +260,9 @@ #ifdef USE_CURL_MULTI
max_requests = DEFAULT_MAX_REQUESTS;
#endif
+ if (getenv("GIT_CURL_FTP_NO_EPSV"))
+ curl_ftp_no_epsv = 1;
+
#ifndef NO_CURL_EASY_DUPHANDLE
curl_default = get_curl_handle();
#endif
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH] http/ftp: optionally ask curl to not use EPSV command
From: Sasha Khapyorsky @ 2006-09-29 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejtvu1ja.fsf@assigned-by-dhcp.cox.net>
On 14:25 Thu 28 Sep , Junio C Hamano wrote:
> Sasha Khapyorsky <sashak@voltaire.com> writes:
>
> > If GIT_CURL_FTP_NO_EPSV environment variable is defined, disable using
> > of EPSV ftp command (PASV will be used instead). This is helpful with
> > some "poor" ftp servers which doesn't support EPSV mode.
> >
> > Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
> > ---
> > http.c | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/http.c b/http.c
> > index 6c1937b..a966e6d 100644
> > --- a/http.c
> > +++ b/http.c
> > @@ -196,6 +196,9 @@ #endif
> >
> > curl_easy_setopt(result, CURLOPT_USERAGENT, GIT_USER_AGENT);
> >
> > + if (getenv("GIT_CURL_FTP_NO_EPSV"))
> > + curl_easy_setopt(result, CURLOPT_FTP_USE_EPSV, 0);
> > +
> > return result;
> > }
> >
> > --
> > 1.4.2.1
>
> Care to match this with existing ones?
>
> $ git grep -e GIT_CURL -e GIT_SSL -e GIT_HTTP
>
> tells you how they are handled and documented. If you spot
> inconsistencies if any (e.g. some having config entry and some
> only environment -- I haven't checked), correcting them while
> you are at it might be a good thing as well.
Make sense. Will rework.
Sasha
^ permalink raw reply
* [PATCH] gitweb: Don't use quotemeta on internally generated strings
From: Luben Tuikov @ 2006-09-28 23:51 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 509 bytes --]
Do not use quotemeta on internally generated strings
such as filenames of snapshot, blobs, etc.
quotemeta quotes any characters not matching /A-Za-z_0-9/.
Which means that we get strings like this:
before: linux\-2\.6\.git\-5c2d97cb31fb77981797fec46230ca005b865799\.tar\.gz
after: linux-2.6.git-5c2d97cb31fb77981797fec46230ca005b865799.tar.gz
This patch fixes this.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
[-- Attachment #2: 541148421-p6.txt --]
[-- Type: text/plain, Size: 1792 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9052647..fdbdb82 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2660,7 +2660,7 @@ sub git_blob_plain {
print $cgi->header(
-type => "$type",
-expires=>$expires,
- -content_disposition => 'inline; filename="' . quotemeta($save_as) . '"');
+ -content_disposition => 'inline; filename="' . "$save_as" . '"');
undef $/;
binmode STDOUT, ':raw';
print <$fd>;
@@ -2835,7 +2835,7 @@ sub git_snapshot {
print $cgi->header(
-type => 'application/x-tar',
-content_encoding => $ctype,
- -content_disposition => 'inline; filename="' . quotemeta($filename) . '"',
+ -content_disposition => 'inline; filename="' . "$filename" . '"',
-status => '200 OK');
my $git_command = git_cmd_str();
@@ -2933,7 +2933,6 @@ sub git_commit {
my @views_nav = ();
if (defined $file_name && defined $co{'parent'}) {
- my $parent = $co{'parent'};
push @views_nav,
$cgi->a({-href => href(action=>"blame", hash_parent=>$parent, file_name=>$file_name)},
"blame");
@@ -3145,7 +3144,7 @@ sub git_blobdiff {
-type => 'text/plain',
-charset => 'utf-8',
-expires => $expires,
- -content_disposition => 'inline; filename="' . quotemeta($file_name) . '.patch"');
+ -content_disposition => 'inline; filename="' . "$file_name" . '.patch"');
print "X-Git-Url: " . $cgi->self_url() . "\n\n";
@@ -3248,7 +3247,7 @@ sub git_commitdiff {
-type => 'text/plain',
-charset => 'utf-8',
-expires => $expires,
- -content_disposition => 'inline; filename="' . quotemeta($filename) . '"');
+ -content_disposition => 'inline; filename="' . "$filename" . '"');
my %ad = parse_date($co{'author_epoch'}, $co{'author_tz'});
print <<TEXT;
From: $co{'author'}
--
1.4.2.1.g05f0f
^ permalink raw reply related
* [PATCH] gitweb: Add snapshot to log; remove redundant commit from log
From: Luben Tuikov @ 2006-09-28 23:50 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
This removes redundant "commit" from log in favor of adding
"snapshot". The commit can be had by clicking on the title of
the entry.
From commit | commitdiff | tree
To commitdiff | tree | snapshot
This makes it consistent with "shortlog".
Adding "snapshot" without removing redundant "commit" makes
it too messy as the log gets out of visual alignment.
I'm ambivalent whether this goes in or not.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
[-- Attachment #2: 458135609-p5.txt --]
[-- Type: text/plain, Size: 821 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 953a0ef..9052647 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2887,11 +2887,11 @@ sub git_log {
$commit);
print "<div class=\"title_text\">\n" .
"<div class=\"log_link\">\n" .
- $cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") .
- " | " .
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") .
" | " .
$cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree") .
+ " | " .
+ $cgi->a({-href => href(action=>"snapshot", hash=>$commit)}, "snapshot") .
"<br/>\n" .
"</div>\n" .
"<i>" . esc_html($co{'author_name'}) . " [$ad{'rfc2822'}]</i><br/>\n" .
--
1.4.2.1.g05f0f
^ permalink raw reply related
* [PATCH] gitweb: Add snapshot to shortlog
From: Luben Tuikov @ 2006-09-28 23:50 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 179 bytes --]
Add snapshot to each commit-row of shortlog.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
[-- Attachment #2: 4046732943-p4.txt --]
[-- Type: text/plain, Size: 672 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a2f07cc..953a0ef 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2021,7 +2021,8 @@ sub git_shortlog_body {
print "</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") . " | " .
- $cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree");
+ $cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree") . " | " .
+ $cgi->a({-href => href(action=>"snapshot", hash=>$commit)}, "snapshot");
print "</td>\n" .
"</tr>\n";
}
--
1.4.2.1.g05f0f
^ permalink raw reply related
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