* [PATCH 1/5] gitweb: Strip trailing slashes from $path in git_get_hash_by_path
From: Jakub Narebski @ 2006-09-25 23:54 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <200609260153.08503.jnareb@gmail.com>
It also removes unused local variable $tree
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 66be619..2ad7eed 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -710,7 +710,7 @@ sub git_get_hash_by_path {
my $path = shift || return undef;
my $type = shift;
- my $tree = $base;
+ $path =~ s,/+$,,;
open my $fd, "-|", git_cmd(), "ls-tree", $base, "--", $path
or die_error(undef, "Open git-ls-tree failed");
--
1.4.2.1
^ permalink raw reply related
* [PATCH 0/5] gitweb: A few code cleanup patches
From: Jakub Narebski @ 2006-09-25 23:53 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
This series of patches, based on 8391548e5e78677eb81f97334d998418802ea194
adds some code cleanups (including validating input and escaping output).
Most deals with changes introduced in
[PATCH] gitweb: Consolidate escaping/validation of query string
commit a2f3db2f5de2a3667b0e038aa65e3e097e642e7d (by Petr Baudis)
Message-ID: <20060923221841.18063.56589.stgit@rover>
Shortlog:
[PATCH 1/5] gitweb: Strip trailing slashes from $path in git_get_hash_by_path
[PATCH 2/5] gitweb: Use "return" instead of "return undef" for some subs
[PATCH 3/5] gitweb: Split validate_input into validate_pathname and validate_refname
[PATCH 4/5] gitweb: Add git_url subroutine, and use it to quote full URLs
[PATCH 5/5] gitweb: Quote filename in HTTP Content-Disposition: header
Diffstat:
gitweb/gitweb.perl | 100 +++++++++++++++++++++++++++++++++++++---------------
1 files changed, 72 insertions(+), 28 deletions(-)
--
Jakub Narebski
ShadeHawk on #git
Warsaw, Poland
^ permalink raw reply
* Re: git send-email woes
From: Sam Ravnborg @ 2006-09-25 21:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7izrzpk2.fsf@assigned-by-dhcp.cox.net>
On Mon, Sep 25, 2006 at 12:58:21PM -0700, Junio C Hamano wrote:
> Sam Ravnborg <sam@ravnborg.org> writes:
>
> > The patches in quistion did not have a "Signed-off-by: tag so
> > that mail address has been from the author instead.
> > And this mail address was still invalid as per RFC2822.
>
> I do not think it takes Signed-off-by: as author in any case
> (and I do not think it should -- if it did so it is a bug).
>
> Maybe something like this?
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 746c525..b4a34f4 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -431,6 +431,11 @@ sub send_message
> $gitversion =~ s/^.* //;
> }
>
> + my ($author_name) = ($from =~ /^(.*?)\s+</);
> + if ($author_name =~ /\./ && $author_name !~ /^".*"$/) {
> + my ($name, $addr) = ($from =~ /^(.*?)(\s+<.*)/);
> + $from = "\"$name\"$addr";
> + }
> my $header = "From: $from
> To: $to
> Cc: $cc
>
I would assume we had to do the same for all mail addresses?
In this case also for $to and $cc and $reply_to.
Sam
^ permalink raw reply
* [PATCH] Use const for interpolate arguments
From: Alex Riesen @ 2006-09-25 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jon Loeliger
In-Reply-To: <E1GPqwJ-0002xt-Bt@jdl.com>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Resending. jdl.com blacklisted my IP, for whatever it has done to him.
interpolate.c | 6 +++---
interpolate.h | 9 +++++++--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/interpolate.c b/interpolate.c
index d82f1b5..4570c12 100644
--- a/interpolate.c
+++ b/interpolate.c
@@ -25,10 +25,10 @@ #include "interpolate.h"
*/
int interpolate(char *result, int reslen,
- char *orig,
- struct interp *interps, int ninterps)
+ const char *orig,
+ const struct interp *interps, int ninterps)
{
- char *src = orig;
+ const char *src = orig;
char *dest = result;
int newlen = 0;
char *name, *value;
diff --git a/interpolate.h b/interpolate.h
index 00c63a5..d16f924 100644
--- a/interpolate.h
+++ b/interpolate.h
@@ -5,6 +5,11 @@
#ifndef INTERPOLATE_H
#define INTERPOLATE_H
+/*
+ * Convert a NUL-terminated string in buffer orig,
+ * performing substitutions on %-named sub-strings from
+ * the interpretation table.
+ */
struct interp {
char *name;
@@ -12,7 +17,7 @@ struct interp {
};
extern int interpolate(char *result, int reslen,
- char *orig,
- struct interp *interps, int ninterps);
+ const char *orig,
+ const struct interp *interps, int ninterps);
#endif /* INTERPOLATE_H */
--
1.4.2.1.g6b47-dirty
^ permalink raw reply related
* Re: git send-email woes
From: David Miller @ 2006-09-25 21:17 UTC (permalink / raw)
To: junkio; +Cc: sam, git
In-Reply-To: <7v7izrzpk2.fsf@assigned-by-dhcp.cox.net>
From: Junio C Hamano <junkio@cox.net>
Date: Mon, 25 Sep 2006 12:58:21 -0700
> Sam Ravnborg <sam@ravnborg.org> writes:
>
> > The patches in quistion did not have a "Signed-off-by: tag so
> > that mail address has been from the author instead.
> > And this mail address was still invalid as per RFC2822.
>
> I do not think it takes Signed-off-by: as author in any case
> (and I do not think it should -- if it did so it is a bug).
>
> Maybe something like this?
That looks like it would do the trick.
^ permalink raw reply
* [PATCH] Use const for interpolate arguments
From: Alex Riesen @ 2006-09-25 21:02 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1GPqwJ-0002xt-Bt@jdl.com>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
interpolate.c | 6 +++---
interpolate.h | 9 +++++++--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/interpolate.c b/interpolate.c
index d82f1b5..4570c12 100644
--- a/interpolate.c
+++ b/interpolate.c
@@ -25,10 +25,10 @@ #include "interpolate.h"
*/
int interpolate(char *result, int reslen,
- char *orig,
- struct interp *interps, int ninterps)
+ const char *orig,
+ const struct interp *interps, int ninterps)
{
- char *src = orig;
+ const char *src = orig;
char *dest = result;
int newlen = 0;
char *name, *value;
diff --git a/interpolate.h b/interpolate.h
index 00c63a5..d16f924 100644
--- a/interpolate.h
+++ b/interpolate.h
@@ -5,6 +5,11 @@
#ifndef INTERPOLATE_H
#define INTERPOLATE_H
+/*
+ * Convert a NUL-terminated string in buffer orig,
+ * performing substitutions on %-named sub-strings from
+ * the interpretation table.
+ */
struct interp {
char *name;
@@ -12,7 +17,7 @@ struct interp {
};
extern int interpolate(char *result, int reslen,
- char *orig,
- struct interp *interps, int ninterps);
+ const char *orig,
+ const struct interp *interps, int ninterps);
#endif /* INTERPOLATE_H */
--
1.4.2.1.g6b47-dirty
^ permalink raw reply related
* Re: [RFC/PATCH] gitweb: Add committags support
From: Petr Baudis @ 2006-09-25 20:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ef95rk$o4q$1@sea.gmane.org>
Dear diary, on Mon, Sep 25, 2006 at 08:06:44PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> So when putting message if into commit message, just put the commit
> message in separate line, perhaps even with some indentation, like
> below:
> Msg-Id: <200609231533.02455.jnareb@gmail.com>
Oh please. :-) The tool should bend, not the user.
Are you going to mandate that for bug references as well? Or should I
proofread all of my commits (if they aren't actually just autoformatted
by fmt without my further review) to verify that they don't actually end
up wrapped, and manually reformat the whole paragraph?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: git send-email woes
From: Junio C Hamano @ 2006-09-25 19:58 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20060925183221.GE2490@uranus.ravnborg.org>
Sam Ravnborg <sam@ravnborg.org> writes:
> The patches in quistion did not have a "Signed-off-by: tag so
> that mail address has been from the author instead.
> And this mail address was still invalid as per RFC2822.
I do not think it takes Signed-off-by: as author in any case
(and I do not think it should -- if it did so it is a bug).
Maybe something like this?
diff --git a/git-send-email.perl b/git-send-email.perl
index 746c525..b4a34f4 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -431,6 +431,11 @@ sub send_message
$gitversion =~ s/^.* //;
}
+ my ($author_name) = ($from =~ /^(.*?)\s+</);
+ if ($author_name =~ /\./ && $author_name !~ /^".*"$/) {
+ my ($name, $addr) = ($from =~ /^(.*?)(\s+<.*)/);
+ $from = "\"$name\"$addr";
+ }
my $header = "From: $from
To: $to
Cc: $cc
^ permalink raw reply related
* Re: git send-email woes
From: Sam Ravnborg @ 2006-09-25 18:32 UTC (permalink / raw)
To: git
In-Reply-To: <20060924224316.GA28051@uranus.ravnborg.org>
On Mon, Sep 25, 2006 at 12:43:16AM +0200, Sam Ravnborg wrote:
> I stumbled on two issues with git-send-email today.
> First of I forgot to tell where to find the patch files to send.
> But git-send-email only complained _after_ I had given all
> the information manually.
> It would have been niver to check that all mandatory arguments
> was present before being interactive.
>
> The second issue are best explained quoting a mail from Matti Arnio:
> > > The GIT is at times producing emails that are not
> > > utterly strictly speaking kosher RFC-(2)822 format.
> > >
> > > It might be a surprise to you that unquoted dots in
> > > people's names cause syntax scanner indigestion,
> > > because said character has very special meaning in
> > > RFC-822 syntax. All would be fine if
> > > Example J.P. Example <example@example.net>
> > > had couple quotes:
> > > "Example J.P. Example" <example@example.net>
>
> What I could see was that git-send-email takes mail address
> verbatim from "Signed-off-by:" lines and use it.
The patches in quistion did not have a "Signed-off-by: tag so
that mail address has been from the author instead.
And this mail address was still invalid as per RFC2822.
> Would it be possible to always quote it except when quoted
> or to do a more intelligent RFC2822 check?
>
> That would keep suprises lower.
>
> I'm not good a perlish so I have not attempted fixing it myself...
Sam
^ permalink raw reply
* Re: [PATCH 1/2] Remove git-zip-tree
From: Rene Scharfe @ 2006-09-25 18:11 UTC (permalink / raw)
To: Franck; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4517B018.4040907@innova-card.com>
Franck Bui-Huu schrieb:
> Subject: [PATCH] git-archive: update documentation
>
> This patch documents zip backend options.
>
> It also adds git-archive command into the main git manual
> page.
Ah, yes. Thanks for catching this omission.
René
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Add committags support
From: Jakub Narebski @ 2006-09-25 18:06 UTC (permalink / raw)
To: git
In-Reply-To: <20060923140535.GK8259@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Sat, Sep 23, 2006 at 03:33:01PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Petr Baudis wrote:
>>
>> > Dear diary, on Sat, Sep 23, 2006 at 10:34:49AM CEST, I got a letter
>> > where Jakub Narebski <jnareb@gmail.com> said that...
>>
>> > Also, there is a fundamental limitation for the multi-word patterns that
>> > they won't work if the line wraps at that point in the log message. This
>> > will likely be a problem especially for the msgids, because those are
>> > very long and are very likely to cause a linewrap immediately before.
>>
>> We do not wrap log messages in gitweb. So the problem is only when
>> commit message is wrongly wrapped itself (pre imples nowrap).
>
> The commit message is not "wrongly" wrapped but just wrapped to fit into
> 72 or whatever columns. It would be silly to mandate users to use msg-id: <200609231533.02455.jnareb@gmail.com>
> with the message id stretching far away just for the sake of some
> gitweb limitations when having the message wrapped such as msg-id:
> <200609231533.02455.jnareb@gmail.com> looks much more reasonable.
So when putting message if into commit message, just put the commit
message in separate line, perhaps even with some indentation, like
below:
Msg-Id: <200609231533.02455.jnareb@gmail.com>
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: fsck objects and timestamp ordering
From: Jon Smirl @ 2006-09-25 17:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0609250951220.3952@g5.osdl.org>
It might be worthwhile to print out a warning on commit if the commit
timestamp is earlier than the previous commit. That might weed out
some people with their clocks set wrong.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: On ref locking
From: Daniel Barkalow @ 2006-09-25 17:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git, Linus Torvalds, Johannes Schindelin
In-Reply-To: <7vmz8o1em0.fsf_-_@assigned-by-dhcp.cox.net>
On Mon, 25 Sep 2006, Junio C Hamano wrote:
> The comments you added to the strawman I sent suggested use of
> rather heavyweight locks, which made me feel we were somehow
> going in a wrong direction. Before going into the details of
> branch removing, let's first see if we can summarize what kind
> of guarantee we would want from ref updates. The current
> locking scheme is very carefully and nicely done by Linus and
> Daniel Barkalow around June last year, and I do not want to lose
> good property of it.
>
> - When reading and/or listing refs you do not need to acquire
> any lock.
>
> - When you are going to update an existing $ref, you create
> $ref.lock, and do a compare-and-swap.
>
> What the latter means is that an updater:
>
> (1) first learns the current value of the $ref, without
> locking;
>
> (2) decides based on the knowledge from (1) what the next value
> should be;
>
> (3) gets $ref.lock, makes sure $ref still is the value it
> learned in (1), updates it to the desired value and
> releases the lock.
>
> The above 3-step sequence prevents updater-updater races with an
> extremely short critical section. We only need to hold the lock
> while we do compare and swap.
I remember having a certain amount of disagreement over whether it's
better to actually take the lock in (1), and hold it through (2), or only
verify that it didn't change in (3) after taking the lock for real. If
there's nothing substantial going on in (2), it doesn't matter. If users
are producing content (e.g., git tag), they may want to make sure that
nobody else is in the middle of writing something that would conflict.
I think I'd advocated getting the lock early if you're going to want it,
and I don't remember what the convincing argument on the other side was
for the cases under consideration at the time, beyond it not mattering
significantly.
Note that we make sure to remove the lock when aborting due to signals
(assuming we get a chance), so the size of the critical section doesn't
matter too much to the chance of it getting left locked inappropriately.
Of course, this is harder to do with the core code for a shell script than
for C code.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: fsck objects and timestamp ordering
From: Linus Torvalds @ 2006-09-25 17:03 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910609250932r146fea7alaaf858a18a8b50b0@mail.gmail.com>
On Mon, 25 Sep 2006, Jon Smirl wrote:
>
> When running fsck objects, does it verify that timestamps are ordered
> in the same order as the dependency chains?
No. In fact, it's perfectly normal that they aren't.
Two machines with different timestamps will think time is different, and
then one side doing a merge may have it's parents "in the future" from
itself.
You can't even solve it sanely: you can't change the other sides
time-stamps after the fact, and correcting the _merge_ timestamp to be
later than both parents is a fix worse than the problem, since it would
tend to just perpetuate a buggy timestamp further down the line.
So this is very fundamental. The first rule of distributed computing is:
"There is no common time". Any distributed project that thinks such a
thing exists is just fundamentally flawed, so I'd have been personally
embarrassed by such a design decision.
So the only thing that matters is always the dependency chain. We've
occasionally discussed having "sequence numbers" or other things to make
it easier to decide on partial ordering between commits without having to
actually follow the whole dependency chain, but times and dates is _never_
a valid thing to use for that.
> I am having trouble with a CVS repository where the timestamp ordering
> and dependency order are in conflict. It would be best if git didn't
> experience the same problem.
It's not really a problem. The timestamps don't "matter". The only thing
git really cares about is the dependency order.
If commit timestamps aren't ordered, some of our programs may look at
unnecessarily many commits because the heuristics use the (committer)
timestamp as a way to guess which leg of a parenthood chain to take, but
that's just a guess.
And the authorship timestamp is never used at all, except purely for
output. So they show up in the log messages, but you can think of them as
nothing more than the commit commentary.
Linus
^ permalink raw reply
* Re: fsck objects and timestamp ordering
From: Shawn Pearce @ 2006-09-25 16:48 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <20060925164004.GB27043@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Jon Smirl <jonsmirl@gmail.com> wrote:
> > I am having trouble with a CVS repository where the timestamp ordering
> > and dependency order are in conflict. It would be best if git didn't
> > experience the same problem.
>
> It would be best if Git didn't experience a lot of the weird stuff
> people were able to do to their CVS repositories. Fortunately the
> friendly folks on this mailing list have put the better part of a
> year and a half into doing just that. :)
Wow, on reread that last sentance seems to imply that the fine
people who have contributed to Git have spent the past year and a
half making sure Git has plenty of weird stuff contained within it.
Which is not what I meant at all. :)
My brain's just not working today (some sort of head cold thing
going on). Its probably best that I stay away from anything that
requires any sort of logic... such as English.
--
Shawn.
^ permalink raw reply
* Re: fsck objects and timestamp ordering
From: Shawn Pearce @ 2006-09-25 16:40 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910609250932r146fea7alaaf858a18a8b50b0@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
> When running fsck objects, does it verify that timestamps are ordered
> in the same order as the dependency chains?
No and it can't. Clock skew between systems could be several
minutes to several hours which means you may have earlier commits
building onto later commits.
The better place to check this (although we don't today) is in
git-commit-tree. If the new commit's committer timestamp is older
than any of its parent's committer timestamps git-commit-tree
should probably at least issue a warning that there's a possible
timestamp problem on either this system or the system that created
one of those parent commits.
If the committer has a problem with that timestamp issue they could
address it and ammend the commit before the error propagates.
> I am having trouble with a CVS repository where the timestamp ordering
> and dependency order are in conflict. It would be best if git didn't
> experience the same problem.
It would be best if Git didn't experience a lot of the weird stuff
people were able to do to their CVS repositories. Fortunately the
friendly folks on this mailing list have put the better part of a
year and a half into doing just that. :)
--
Shawn.
^ permalink raw reply
* Re: [laroche@redhat.com: gitweb.cgi]
From: Jakub Narebski @ 2006-09-25 16:32 UTC (permalink / raw)
To: git
In-Reply-To: <20060925161934.GA18951@dudweiler.stuttgart.redhat.com>
Florian La Roche wrote:
> Hello git crew,
>
> I'm not a big perl prorammer, but the following removes perl
> warnings about accessing undefined vars.
[...]
> --- gitweb/gitweb.perl
> +++ gitweb/gitweb.perl
> @@ -427,7 +427,9 @@ sub esc_html {
> my $str = shift;
> $str = decode("utf8", $str, Encode::FB_DEFAULT);
> $str = escapeHTML($str);
> - $str =~ s/\014/^L/g; # escape FORM FEED (FF) character (e.g. in COPYING file)
> + if (defined $str) {
> + $str =~ s/\014/^L/g; # escape FORM FEED (FF) character (e.g. in COPYING file)
> + }
> return $str;
> }
>
It would be better to just use
my $str = shift;
return '' unless defined $str;
and neither your change in esc_html, nor the change below should be needed.
By the way, commit without title? But it would be better if correct it, to
set $co{'title'} to an empty string, either in git_log or in parse_commit.
> @@ -2860,10 +2819,14 @@ sub git_log {
> my $ref = format_ref_marker($refs, $commit);
> my %co = parse_commit($commit);
> next if !%co;
> + my $esc_title = $co{'title'};
> + if (defined $esc_title) {
> + $esc_title = esc_html($esc_title);
> + }
> my %ad = parse_date($co{'author_epoch'});
> git_print_header_div('commit',
> "<span class=\"age\">$co{'age_string'}</span>" .
> - esc_html($co{'title'}) . $ref,
> + $esc_title . $ref,
> $commit);
> print "<div class=\"title_text\">\n" .
> "<div class=\"log_link\">\n" .
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* fsck objects and timestamp ordering
From: Jon Smirl @ 2006-09-25 16:32 UTC (permalink / raw)
To: Git Mailing List
When running fsck objects, does it verify that timestamps are ordered
in the same order as the dependency chains?
I am having trouble with a CVS repository where the timestamp ordering
and dependency order are in conflict. It would be best if git didn't
experience the same problem.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [laroche@redhat.com: gitweb.cgi]
From: Florian La Roche @ 2006-09-25 16:19 UTC (permalink / raw)
To: git
Hello git crew,
I'm not a big perl prorammer, but the following removes perl
warnings about accessing undefined vars.
regards,
Florian La Roche
--- gitweb/gitweb.perl
+++ gitweb/gitweb.perl
@@ -427,7 +427,9 @@ sub esc_html {
my $str = shift;
$str = decode("utf8", $str, Encode::FB_DEFAULT);
$str = escapeHTML($str);
- $str =~ s/\014/^L/g; # escape FORM FEED (FF) character (e.g. in COPYING file)
+ if (defined $str) {
+ $str =~ s/\014/^L/g; # escape FORM FEED (FF) character (e.g. in COPYING file)
+ }
return $str;
}
@@ -2860,10 +2819,14 @@ sub git_log {
my $ref = format_ref_marker($refs, $commit);
my %co = parse_commit($commit);
next if !%co;
+ my $esc_title = $co{'title'};
+ if (defined $esc_title) {
+ $esc_title = esc_html($esc_title);
+ }
my %ad = parse_date($co{'author_epoch'});
git_print_header_div('commit',
"<span class=\"age\">$co{'age_string'}</span>" .
- esc_html($co{'title'}) . $ref,
+ $esc_title . $ref,
$commit);
print "<div class=\"title_text\">\n" .
"<div class=\"log_link\">\n" .
^ permalink raw reply
* [PATCH] Clarified documentation of --exclude-per-directory.
From: Shawn Pearce @ 2006-09-25 15:58 UTC (permalink / raw)
To: git
Tommi Virtanen noted on #git today that
git ls-files --exclude-per-directory
doesn't appear to work as advertised by the documentation unless
--others is also used. According to the current source code this
is the case as the --exclude-per-directory file isn't read unless
we are iterating over the working directory, which only happens
with --others.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-ls-files.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 8520b97..2a0b9f8 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -75,7 +75,8 @@ OPTIONS
--exclude-per-directory=<file>::
read additional exclude patterns that apply only to the
- directory and its subdirectories in <file>.
+ directory and its subdirectories in <file>. This option
+ only takes effect if -o or --others is also used.
--error-unmatch::
If any <file> does not appear in the index, treat this as an
@@ -167,7 +168,7 @@ time. They are built and ordered in the
* lines read from --exclude-from=<file>; patterns are ordered
in the same order as they appear in the file.
- * When --exclude-per-directory=<name> is specified, upon
+ * When --exclude-per-directory=<name> and --others is specified, upon
entering a directory that has such a file, its contents are
appended at the end of the current "list of patterns". They
are popped off when leaving the directory.
--
1.4.2.1.g7a39b
^ permalink raw reply related
* Re: The GPL: No shelter for the Linux kernel?
From: Linus Torvalds @ 2006-09-25 15:14 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Petr Baudis, David Schwartz, linux-kernel, git
In-Reply-To: <Pine.LNX.4.61.0609250757070.18552@yvahk01.tjqt.qr>
On Mon, 25 Sep 2006, Jan Engelhardt wrote:
>
> Though I strongly agree with you, some GNU folks (such as
> savannah.nongnu.org) seem to explicitly require it, even for files
> that do not make up a single program (i.e. like coreutils/ls.c).
Each project obviously has its own rules. The kernel, in many ways, these
days does something even stronger, in the sense that we now ask not that
every file be marked, but each and every change be signed-off-on. It's
more than a copyright issue, of course (it started out motivated by the
worries of tracking codeflow, but I think one reason it has worked so well
is that it's become useful for so many other things).
So lots of projects have their specific rules. I don't think the "add
notice to every file" is wrong per se, I just think it's impractical: not
only does it get unwieldly with all those messages at the top, usually an
open source project ends up being a mix of lots of different people that
own rights in it, and in many ways it's thus better to track at a change
level rather than a file level if you do tracking.
But exactly because it doesn't have any real legal rules, the rules are
from other sources, and boil down mainly to just per-project "coding
style" issues.
Linus
^ permalink raw reply
* [PATCH] gitk: Fix nextfile() and more
From: OGAWA Hirofumi @ 2006-09-25 13:46 UTC (permalink / raw)
To: git
Hi,
The current nextfile() jumps to last hunk, but I think this is not
intention, probably, it's forgetting to add "break;". Right? And this
patch also adds prevfile(), it jumps to previous hunk.
The following part is just my favorite the key-binds, it doesn't matter.
+ bind . <Control-p> "$ctext yview scroll -1 units"
+ bind . <Control-n> "$ctext yview scroll 1 units"
+ bind . <Alt-v> "$ctext yview scroll -1 pages"
+ bind . <Control-v> "$ctext yview scroll 1 pages"
+ bindkey P prevfile
+ bindkey N nextfile
What do you think of this?
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---
gitk | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff -puN gitk~gitk-key-emacs gitk
--- git/gitk~gitk-key-emacs 2006-09-25 22:31:51.000000000 +0900
+++ git-hirofumi/gitk 2006-09-25 22:31:51.000000000 +0900
@@ -672,6 +672,10 @@ proc makewindow {} {
bind . <Control-Key-Down> "allcanvs yview scroll 1 units"
bind . <Control-Key-Prior> "allcanvs yview scroll -1 pages"
bind . <Control-Key-Next> "allcanvs yview scroll 1 pages"
+ bind . <Control-p> "$ctext yview scroll -1 units"
+ bind . <Control-n> "$ctext yview scroll 1 units"
+ bind . <Alt-v> "$ctext yview scroll -1 pages"
+ bind . <Control-v> "$ctext yview scroll 1 pages"
bindkey <Key-Delete> "$ctext yview scroll -1 pages"
bindkey <Key-BackSpace> "$ctext yview scroll -1 pages"
bindkey <Key-space> "$ctext yview scroll 1 pages"
@@ -690,6 +694,8 @@ proc makewindow {} {
bindkey <Key-Return> {findnext 0}
bindkey ? findprev
bindkey f nextfile
+ bindkey P prevfile
+ bindkey N nextfile
bind . <Control-q> doquit
bind . <Control-f> dofind
bind . <Control-g> {findnext 0}
@@ -4440,12 +4446,26 @@ proc getblobdiffline {bdf ids} {
}
}
+proc prevfile {} {
+ global difffilestart ctext
+ set prev [lindex $difffilestart 0]
+ set here [$ctext index @0,0]
+ foreach loc $difffilestart {
+ if {[$ctext compare $loc >= $here]} {
+ $ctext yview $prev
+ break
+ }
+ set prev $loc
+ }
+}
+
proc nextfile {} {
global difffilestart ctext
set here [$ctext index @0,0]
foreach loc $difffilestart {
if {[$ctext compare $loc > $here]} {
$ctext yview $loc
+ break
}
}
}
_
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Catalin Marinas @ 2006-09-25 12:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Linus Torvalds, git
In-Reply-To: <20060924205455.GA20017@pasky.or.cz>
On 24/09/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sat, Sep 23, 2006 at 03:10:17PM CEST, I got a letter
> where Catalin Marinas <catalin.marinas@gmail.com> said that...
> > I wasn't following this thread (well, any thread in the last days) but
> > the current patch history implementation in StGIT is prune-safe as it
> > generates additional commits to keep the history. If you undo an
> > operation (push, refresh), the undo will be recorded in the patch
> > history (that's really immutable)
>
> It does not directly reference the history in the additional commits
> though, it just mentions the sha1 in the log message - that is not
> prune-safe:
Yes, indeed (I'm still tired :-)). The patch changes are safe and one
could probably generate the patch from them but it's a bit more
complicated. The quick solution is to add another parent to the
changelog commit so that it points to the patch. However, this
wouldn't look as nice with gitk as it sees them as merges and doesn't
display the diff (is there an option I missed?).
--
Catalin
^ permalink raw reply
* Re: [PATCH] perl bindings fix compilation errors
From: Johannes Schindelin @ 2006-09-25 11:38 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <4517BEBC.4000002@shadowen.org>
Hi,
On Mon, 25 Sep 2006, Andy Whitcroft wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Mon, 25 Sep 2006, Andy Whitcroft wrote:
> >
> >> With the introduction of Makefile.PL to the perl bindings we no
> >> longer seem to pass in either the definition of SHA1_HEADER or
> >> GIT_VERSION. It seems we no longer pass over the BASIC_FLAGS into
> >> the compilation.
> >
> > You probably got bitten by the fact that earlier runs left Git.c in the
> > perl/ directory. Go to perl/, "make distclean", and make git again.
>
> Hmmm that sucks. Yes, I had to make distclean more than once, but it
> seems to fix things.
>
> I am somewhat unhappy that a make clean at the top level and remake was
> not sufficient to get a working tree.
Yes. I almost submitted a patch which checks for perl/Git.c, and makes
distclean in perl/ if exists.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] perl bindings fix compilation errors
From: Andy Whitcroft @ 2006-09-25 11:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609251223590.25371@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 25 Sep 2006, Andy Whitcroft wrote:
>
>> With the introduction of Makefile.PL to the perl bindings we no
>> longer seem to pass in either the definition of SHA1_HEADER or
>> GIT_VERSION. It seems we no longer pass over the BASIC_FLAGS into
>> the compilation.
>
> You probably got bitten by the fact that earlier runs left Git.c in the
> perl/ directory. Go to perl/, "make distclean", and make git again.
Hmmm that sucks. Yes, I had to make distclean more than once, but it
seems to fix things.
I am somewhat unhappy that a make clean at the top level and remake was
not sufficient to get a working tree.
-apw
^ 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