* Re: [PATCH] Add Pascal/Delphi (.pas file) funcname pattern.
From: Avery Pennarun @ 2008-08-01 20:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080801202059.GS32184@machine.or.cz>
On 8/1/08, Petr Baudis <pasky@suse.cz> wrote:
> On Fri, Aug 01, 2008 at 03:45:15PM -0400, Avery Pennarun wrote:
> > + { "pas", "\\(^\\(procedure\\|function\\|constructor\\|"
> > + "destructor\\|interface\\|implementation\\|"
> > + "type|initialization|finalization\\).*$\\)"
> > + "\\|\\(^.*=[ \t]*\\(class\\|record\\).*$\\)" },
>
> Wouldn't it be better to make the second pattern start on new line
> instead of the outer \(\|\)?
I didn't even know that was possible, but suddenly I understand the
"java" pattern a lot better. Thanks!
> Why "type"?
Well, it's a subsection, but it's always followed by a class or record
definition anyway, so I guess it makes more sense to omit it, now that
you bring it up.
Have fun,
Avery
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 20:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0808011335230.3277@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008, Linus Torvalds wrote:
>
> If you want to turn it into emails, you need to follow the email rules.
> You're cutting-and-pasting anyway, it's not like this is fundamentally
> hard.
Btw, if sending emails was the _only_ thing that Author line was used for,
or even the main thing, then it would make sense to keep it in some email
format. But it really isn't. Sending emails to people is the _least_
common thing you do with it. Most of the time you just want to see the
name in a nice readable format.
Linus
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 20:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0808011335230.3277@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008 13:40:00 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 1 Aug 2008, Andrew Morton wrote:
> >
> > pls read earlier email.
>
> I did. It seems that your complaint is:
>
> > So unless he explicitly typed a "From:" line (without quoting his name)
> > into the top of his changelog, some piece of software somewhere has
> > stripped the quotes when it was converting his name from the email
> > headers into the git Author: line.
>
> And yes, git will strip out all the crap and try to make it into a real
> name.
>
> The part _you_ don't seem to understand is that my point is
>
> - git changed that "From:" line to an "Author:" line
>
> - "git log" isn't an email system. It's a human-readable (and
> machine-parseable, for that matter) log.
What you're describing here is some explicit or implicit git design
decision and then telling me how it's implemented.
Well, what I'm saying is that it was an incorrect design decision.
> If you want to turn it into emails, you need to follow the email rules.
> You're cutting-and-pasting anyway, it's not like this is fundamentally
> hard.
Here is a real story from a real user of your software:
I very very frequently copy and paste name+email address out of git
output and into an MUA. Have done it thousands and thousands of times,
and it has always worked. I'm sure that many others do the same thing.
Yesterday, I copied and pasted what _looked_ like a usable
name+email-address from some git output and into an MUA. Unlike the
thousands of preceding times, it did not work.
I think it was reasonable of me to assume that it would work. Blaming
the surprised and misled user for not understanding some earlier
internal design decision didn't satisfy him!
True story! From a user.
^ permalink raw reply
* [PATCH] Add Pascal/Delphi (.pas file) funcname pattern.
From: Avery Pennarun @ 2008-08-01 21:00 UTC (permalink / raw)
To: gitster, git, pasky; +Cc: Avery Pennarun
Finds classes, records, functions, procedures, and sections. Most lines
need to start at the first column, or else there's no way to differentiate
a procedure's definition from its declaration.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
---
diff.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
Changes since v1:
- Tried using '\n' to separate the two parts of the regex, but it doesn't
work. Seems the lines are combined with AND instead of OR. Also can't
reduce the number of parens since only the part in parens is returned
as the result string.
- Rename 'pas' type to 'pascal'
- Remove unnecessary 'type' match.
diff --git a/diff.c b/diff.c
index cbf2547..2f88e6d 100644
--- a/diff.c
+++ b/diff.c
@@ -1380,6 +1380,12 @@ static struct builtin_funcname_pattern {
"^[ ]*\\(\\([ ]*"
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
"[ ]*([^;]*\\)$" },
+ { "pascal", "^\\(\\(procedure\\|function\\|constructor\\|"
+ "destructor\\|interface\\|implementation\\|"
+ "initialization\\|finalization\\)[ \t]*.*\\)$"
+ "\\|"
+ "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$"
+ },
{ "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
};
--
1.5.6
^ permalink raw reply related
* Re: email address handling
From: Johannes Schindelin @ 2008-08-01 21:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, git
In-Reply-To: <20080801135421.5ca0f6af.akpm@linux-foundation.org>
Hi,
On Fri, 1 Aug 2008, Andrew Morton wrote:
> I very very frequently copy and paste name+email address out of git
> output and into an MUA. Have done it thousands and thousands of times,
> and it has always worked. I'm sure that many others do the same thing.
$ git log --pretty=email
after this patch:
-- snipsnap --
pretty.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index 33ef34a..ba50b54 100644
--- a/pretty.c
+++ b/pretty.c
@@ -140,14 +140,20 @@ void pp_user_info(const char *what, enum cmit_fmt fmt, struct strbuf *sb,
if (fmt == CMIT_FMT_EMAIL) {
char *name_tail = strchr(line, '<');
int display_name_length;
+ int need_quotes;
if (!name_tail)
return;
while (line < name_tail && isspace(name_tail[-1]))
name_tail--;
display_name_length = name_tail - line;
+ need_quotes = !!memchr(line, ',', display_name_length);
filler = "";
strbuf_addstr(sb, "From: ");
+ if (need_quotes)
+ strbuf_addch(sb, '"');
add_rfc2047(sb, line, display_name_length, encoding);
+ if (need_quotes)
+ strbuf_addch(sb, '"');
strbuf_add(sb, name_tail, namelen - display_name_length);
strbuf_addch(sb, '\n');
} else {
^ permalink raw reply related
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 21:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20080801135421.5ca0f6af.akpm@linux-foundation.org>
On Fri, 1 Aug 2008, Andrew Morton wrote:
>
> Well, what I'm saying is that it was an incorrect design decision.
And I'm saying that I disagree.
> Yesterday, I copied and pasted what _looked_ like a usable
> name+email-address from some git output and into an MUA. Unlike the
> thousands of preceding times, it did not work.
>
> I think it was reasonable of me to assume that it would work. Blaming
> the surprised and misled user for not understanding some earlier
> internal design decision didn't satisfy him!
>
> True story! From a user.
Hey, there are tons of surprises in life. Users make mistakes and
assumptions that turn out to not be true. If you think you can avoid all
such issues, I think you aren't living in the real world.
You'll be shocked to hear that even the so-called _email_ address isn't
necessarily valid at all at times. Look closer, and you'll find email
addresses that don't work at all. It turns out that if you don't set it
explicitly, git will guess, and sometimes the end result won't actually
work as an email address.
Beign surprised and then saying "I was surprised, so the whole design is
broken" - that's a very silly standpoint to make. I suggest you
reconsider. How many times have you had people "surprised" by correct
kernel behaviour? Happens all the time.
Do you think they are all indicative of bad design, or maybe just "welcome
to the real world - your preconceived notions didn't turn out to be
accurate after all"?
It's a design decision to show the name as readably as possible. One that
I think was correct.
Linus
^ permalink raw reply
* Re: email address handling
From: Junio C Hamano @ 2008-08-01 21:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andrew Morton, Linus Torvalds, git
In-Reply-To: <alpine.DEB.1.00.0808012314580.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 1 Aug 2008, Andrew Morton wrote:
>
>> I very very frequently copy and paste name+email address out of git
>> output and into an MUA. Have done it thousands and thousands of times,
>> and it has always worked. I'm sure that many others do the same thing.
>
> $ git log --pretty=email
>
> after this patch:
You are quoting only Author: and not Signed-off-by: and Cc: that are used
for e-mail purposes. I already said send-email is the right place to do
this kind of thing, didn't I? Your patch makes things worse by making
some <name, mail> pair already quoted and some others don't.
Please don't do this.
^ permalink raw reply
* Re: email address handling
From: Junio C Hamano @ 2008-08-01 21:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, git
In-Reply-To: <20080801135421.5ca0f6af.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
>> The part _you_ don't seem to understand is that my point is
>>
>> - git changed that "From:" line to an "Author:" line
>>
>> - "git log" isn't an email system. It's a human-readable (and
>> machine-parseable, for that matter) log.
>
> What you're describing here is some explicit or implicit git design
> decision and then telling me how it's implemented.
>
> Well, what I'm saying is that it was an incorrect design decision.
What is the objective of your statement in this discussion? Further add
fuel to flame, or to seek avenues that lead to some improvement in a
constructive way?
The thing is, I do not think reverting that design decision is an option
at this point. People's repositories record <Name, Email> pair already in
"human readable" form, and people's scripts are assuming that.
I misspoke about git-send-email earlier; it already has sanitize_address()
that massages the addresses on From: To: and Cc: lines. In fact, it even
seems to have logic to avoid double-quoting, so it would be Ok if you
changed the design decision this late in the game for that particular
script, but that does not mean it is a good change --- other scripts
people may have built around git would need to change.
So the earlier patch from Dscho (Johannes) may be a step in the right
direction, but if we are going to rewrite the author information, (1) it
has to be an option, and (2) when rewriting, it should not be just From:;
but Signed-off-by:, Cc: and other <Name, Email> pairs at the end of the
log message would need similar treatment, so that you can cut and paste
any of them to your MUA.
^ permalink raw reply
* More on git over HTTP POST
From: H. Peter Anvin @ 2008-08-01 21:50 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I have investigated a bit what it would take to support git protocol
(smart transport) over HTTP POST transactions.
The current proxy system is broken, for a very simple reason: it doesn't
convey information about when the channel should be turned around.
HTTP POST -- or, for that matter, any RPC-style transport, is a half
duplex transport: only one direction can be active at a time, after
which the channel has to be explicitly turned around. The "turning
around" consists of posting the queued transaction and listening for the
reply.
Ultimately, it comes down to the following: the transactor needs to be
given explicit information when the git protocol goes from writing to
reading (the opposite direction information is obvious.) I was hoping
that it would be possible to get this information from snooping the
protocol, but it doesn't seem to be so lucky.
I started to hack on a variant which would embed a VFS-style interface
in git itself, looking something like:
struct transactor;
struct transact_ops {
ssize_t (*read)(struct transactor *, void *, size_t);
ssize_t (*write)(struct transactor *, const void *, size_t);
int (*close)(struct transactor *);
};
struct transactor {
union {
void *p;
intptr_t i;
} u;
const struct transact_ops *ops;
};
Replacing the usual fd operations with this interface would allow a
different transactor to see the phase changes explicitly; the
replacement to use xread() and xwrite() is obvious.
Of course, I started hacking on it and found myself with zero time to
continue, but I thought I'd post what I had come up with.
-hpa
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, git
In-Reply-To: <7vvdykqub6.fsf@gitster.siamese.dyndns.org>
On Fri, 01 Aug 2008 14:50:05 -0700
Junio C Hamano <gitster@pobox.com> wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
> >> The part _you_ don't seem to understand is that my point is
> >>
> >> - git changed that "From:" line to an "Author:" line
> >>
> >> - "git log" isn't an email system. It's a human-readable (and
> >> machine-parseable, for that matter) log.
> >
> > What you're describing here is some explicit or implicit git design
> > decision and then telling me how it's implemented.
> >
> > Well, what I'm saying is that it was an incorrect design decision.
>
> What is the objective of your statement in this discussion? Further add
> fuel to flame, or to seek avenues that lead to some improvement in a
> constructive way?
Well initially it was to work out why the heck my git-log output had
stripped the quotes from that person's name, making it unusable for
email purposes. I'd actually assumed that it was a bug.
> The thing is, I do not think reverting that design decision is an option
> at this point. People's repositories record <Name, Email> pair already in
> "human readable" form, and people's scripts are assuming that.
>
> I misspoke about git-send-email earlier; it already has sanitize_address()
> that massages the addresses on From: To: and Cc: lines. In fact, it even
> seems to have logic to avoid double-quoting, so it would be Ok if you
> changed the design decision this late in the game for that particular
> script, but that does not mean it is a good change --- other scripts
> people may have built around git would need to change.
>
> So the earlier patch from Dscho (Johannes) may be a step in the right
> direction, but if we are going to rewrite the author information, (1) it
> has to be an option, and (2) when rewriting, it should not be just From:;
> but Signed-off-by:, Cc: and other <Name, Email> pairs at the end of the
> log message would need similar treatment, so that you can cut and paste
> any of them to your MUA.
I preserve the quotes (when present) in signoffs for this exact reason.
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Dmitry Potapov @ 2008-08-01 22:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git, Eric Wong
In-Reply-To: <7vmyjwserv.fsf@gitster.siamese.dyndns.org>
On Fri, Aug 01, 2008 at 12:42:44PM -0700, Junio C Hamano wrote:
>
> Ok, earlier I was confused who was proposing what for what purpose, but
> that one was not just "a bit hackish" but an unacceptable hack ;-)
Thanks for correct my wording ;-)
>
> Perhaps you would want to do the s/write_object/flags/ conversion, like
> this?
Yes, it was my prefered choice to change these index_xx functions.
I have applied your patch and then corrected mine to use flags.
See below.
I wonder if something should be done about other places where index_xx
functions are called. I have looked at them and all they use either 0 or
1 (boolean expression which will be evaluated to 0 or 1), so they should
work as is, but I can correct them to use HASH_OBJECT_DO_CREATE instead
of 1 if it helps with readability.
-- 8< --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Thu, 31 Jul 2008 21:10:26 +0400
Subject: [PATCH] hash-object --no-filters
The --no-filters option makes git hash-object to work as there were no
input filters. This option is useful for importers such as git-svn to
put new version of files as is even if autocrlf is set.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
Documentation/git-hash-object.txt | 6 ++++++
hash-object.c | 28 +++++++++++++++-------------
2 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
index ac928e1..69a17c7 100644
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt
@@ -35,6 +35,12 @@ OPTIONS
--stdin-paths::
Read file names from stdin instead of from the command-line.
+--no-filters::
+ If this option is given then the file is hashed as is ignoring
+ all filters specified in the configuration, including crlf
+ conversion. If the file is read from standard input then no
+ filters is always implied.
+
Author
------
Written by Junio C Hamano <gitster@pobox.com>
diff --git a/hash-object.c b/hash-object.c
index 46c06a9..2dd7283 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -8,7 +8,7 @@
#include "blob.h"
#include "quote.h"
-static void hash_object(const char *path, enum object_type type, int write_object)
+static void hash_object(const char *path, enum object_type type, int flags)
{
int fd;
struct stat st;
@@ -16,23 +16,23 @@ static void hash_object(const char *path, enum object_type type, int write_objec
fd = open(path, O_RDONLY);
if (fd < 0 ||
fstat(fd, &st) < 0 ||
- index_fd(sha1, fd, &st, write_object, type, path))
- die(write_object
+ index_fd(sha1, fd, &st, flags, type, path))
+ die((flags & HASH_OBJECT_DO_CREATE)
? "Unable to add %s to database"
: "Unable to hash %s", path);
printf("%s\n", sha1_to_hex(sha1));
maybe_flush_or_die(stdout, "hash to stdout");
}
-static void hash_stdin(const char *type, int write_object)
+static void hash_stdin(const char *type, int flags)
{
unsigned char sha1[20];
- if (index_pipe(sha1, 0, type, write_object))
+ if (index_pipe(sha1, 0, type, flags))
die("Unable to add stdin to database");
printf("%s\n", sha1_to_hex(sha1));
}
-static void hash_stdin_paths(const char *type, int write_objects)
+static void hash_stdin_paths(const char *type, int flags)
{
struct strbuf buf, nbuf;
@@ -45,7 +45,7 @@ static void hash_stdin_paths(const char *type, int write_objects)
die("line is badly quoted");
strbuf_swap(&buf, &nbuf);
}
- hash_object(buf.buf, type_from_string(type), write_objects);
+ hash_object(buf.buf, type_from_string(type), flags);
}
strbuf_release(&buf);
strbuf_release(&nbuf);
@@ -58,7 +58,7 @@ int main(int argc, char **argv)
{
int i;
const char *type = blob_type;
- int write_object = 0;
+ int flags = 0;
const char *prefix = NULL;
int prefix_length = -1;
int no_more_flags = 0;
@@ -80,7 +80,7 @@ int main(int argc, char **argv)
prefix_length =
prefix ? strlen(prefix) : 0;
}
- write_object = 1;
+ flags |= HASH_OBJECT_DO_CREATE;
}
else if (!strcmp(argv[i], "--")) {
no_more_flags = 1;
@@ -104,6 +104,8 @@ int main(int argc, char **argv)
die("Multiple --stdin arguments are not supported");
hashstdin = 1;
}
+ else if (!strcmp(argv[i], "--no-filters"))
+ flags |= HASH_OBJECT_LITERALLY;
else
usage(hash_object_usage);
}
@@ -116,21 +118,21 @@ int main(int argc, char **argv)
}
if (hashstdin) {
- hash_stdin(type, write_object);
+ hash_stdin(type, flags);
hashstdin = 0;
}
if (0 <= prefix_length)
arg = prefix_filename(prefix, prefix_length,
arg);
- hash_object(arg, type_from_string(type), write_object);
+ hash_object(arg, type_from_string(type), flags);
no_more_flags = 1;
}
}
if (stdin_paths)
- hash_stdin_paths(type, write_object);
+ hash_stdin_paths(type, flags);
if (hashstdin)
- hash_stdin(type, write_object);
+ hash_stdin(type, flags);
return 0;
}
--
1.6.0.rc1.33.gb756f
^ permalink raw reply related
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Junio C Hamano @ 2008-08-01 22:14 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alexander Litvinov, git, Eric Wong
In-Reply-To: <20080801220932.GK7008@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> writes:
> I have applied your patch and then corrected mine to use flags.
> See below.
>
> I wonder if something should be done about other places where index_xx
> functions are called. I have looked at them and all they use either 0 or
> 1 (boolean expression which will be evaluated to 0 or 1), so they should
> work as is, but I can correct them to use HASH_OBJECT_DO_CREATE instead
> of 1 if it helps with readability.
Even though the patch was not compile tested, I did check the existing
call sites are giving only 0 or 1, but I think converting these "please
write -- I give you 1" callers to pass the bitmask would be a sane thing
to do.
^ permalink raw reply
* Re: email address handling
From: Theodore Tso @ 2008-08-01 22:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Junio C Hamano, torvalds, git
In-Reply-To: <20080801145804.85041bbd.akpm@linux-foundation.org>
On Fri, Aug 01, 2008 at 02:58:04PM -0700, Andrew Morton wrote:
>
> I preserve the quotes (when present) in signoffs for this exact reason.
>
Heh. I include quotes in my Signed-off-by:
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Because I assumed the format of the DCO was an RFC-822 compliant
header format. It otherwise *looks* like an RFC-822 format, so I
assumed it should follow all of the rules, including the ones about
quoting.
How about this as a compromise? Git continues to store the names in
its internal format as it always does, but there is a configuration
option which controls whether the various Author: and Committer:
fields when displayd by git-log are in RFC-822 format or not.
- Ted
^ permalink raw reply
* [PATCH 1/2] gitweb: parse parent..current syntax from pathinfo
From: Giuseppe Bilotta @ 2008-08-01 22:17 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Giuseppe Bilotta
In-Reply-To: <1217622913-9747-1-git-send-email-giuseppe.bilotta@gmail.com>
This makes it possible to use an URL such as
$project/somebranch..otherbranch:/filename to get a diff between
different version of a file. Paths like
$project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
as well.
---
This patch and the next apply on top of my previous two
gitweb pathinfo patches.
I realize that these patches of mine coming through in burst
can get pretty annoying, but I honestly wasn't planning of
making so many changes to the path info feature. So let me
know if it's better to resend the patches in a series.
Hopefully, with this patch and the next the series should be
complete, as most commands will now be able to get all of
their parameters from the path without using CGI parameters.
gitweb/gitweb.perl | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9e90017..8364b71 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -578,7 +578,9 @@ sub evaluate_path_info {
$action = undef;
}
- my ($refname, $pathname) = split(/:/, $path_info, 2);
+ $path_info =~ /^((.+?)(:(.+))?\.\.)?(.+?)(:(.+))?$/;
+ my ($parentrefname, $parentpathname, $refname, $pathname) = (
+ $2, $4, $5, $7);
if (defined $pathname) {
# we got "project.git/branch:filename" or "project.git/branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
@@ -587,11 +589,27 @@ sub evaluate_path_info {
$action ||= "tree";
$pathname =~ s,/$,,;
} else {
- $action ||= "blob_plain";
+ if ($parentrefname) {
+ $action ||= "blobdiff_plain";
+ } else {
+ $action ||= "blob_plain";
+ }
}
$hash_base ||= validate_refname($refname);
$file_name ||= validate_pathname($pathname);
$hash ||= git_get_hash_by_path($hash_base, $file_name);
+
+ if ($parentrefname) {
+ $hash_parent_base ||= validate_refname($parentrefname);
+ if ($parentpathname) {
+ $parentpathname =~ s,^/+,,;
+ $parentpathname =~ s,/$,,;
+ $file_parent ||= validate_pathname($parentpathname);
+ } else {
+ $file_parent ||= $file_name
+ }
+ $hash_parent ||= git_get_hash_by_path($hash_parent_base, $file_parent);
+ }
} elsif (defined $refname) {
# we got "project.git/branch"
$action ||= "shortlog";
--
1.5.6.3
^ permalink raw reply related
* [PATCH 2/2] gitweb: use_pathinfo creates parent..current paths
From: Giuseppe Bilotta @ 2008-08-01 22:17 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Giuseppe Bilotta
In-Reply-To: <1217629031-14894-1-git-send-email-giuseppe.bilotta@gmail.com>
If use_pathinfo is enabled, href now creates links that contain paths in
the form $project/$action/oldhash:/oldname..newhash:/newname for actions
that use hash_parent etc.
---
gitweb/gitweb.perl | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8364b71..e89e1a1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -703,9 +703,29 @@ sub href (%) {
delete $params{'action'};
}
- # next, we put either hash_base:file_name or hash
+ # next, we put hash_parent_base:/file_parent..hash_base:/file_name, stripping nonexistent or useless pieces
+ $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'} || $params{'hash_parent'} || $params{'hash'});
if (defined $params{'hash_base'}) {
- $href .= "/".esc_url($params{'hash_base'});
+ if (defined $params{'hash_parent_base'}) {
+ $href .= esc_url($params{'hash_parent_base'});
+ if (defined $params{'file_parent'}) {
+ $href .= ":/".esc_url($params{'file_parent'}) unless $params{'file_parent'} eq $params{'file_name'};
+ delete $params{'hash_parent'} if $params{'hash_parent'} eq git_get_hash_by_path($params{'hash_parent_base'},$params{'file_parent'});
+ delete $params{'file_parent'};
+ } else {
+ delete $params{'hash_parent'} if $params{'hash_parent'} eq $params{'hash_parent_base'};
+ if ($params{'file_name'}) {
+ delete $params{'hash_parent'} if $params{'hash_parent'} eq git_get_hash_by_path($params{'hash_parent_base'},$params{'file_name'});
+ }
+ }
+ $href .= "..";
+ delete $params{'hash_parent_base'};
+ } elsif (defined $params{'hash_parent'}) {
+ $href .= esc_url($params{'hash_parent'}). "..";
+ delete $params{'hash_parent'};
+ }
+
+ $href .= esc_url($params{'hash_base'});
if (defined $params{'file_name'}) {
$href .= ":/".esc_url($params{'file_name'});
delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
@@ -715,7 +735,7 @@ sub href (%) {
}
delete $params{'hash_base'};
} elsif (defined $params{'hash'}) {
- $href .= "/".esc_url($params{'hash'});
+ $href .= esc_url($params{'hash'});
delete $params{'hash'};
}
}
--
1.5.6.3
^ permalink raw reply related
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 22:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: Junio C Hamano, git
In-Reply-To: <20080801145804.85041bbd.akpm@linux-foundation.org>
On Fri, 1 Aug 2008, Andrew Morton wrote:
>
> I preserve the quotes (when present) in signoffs for this exact reason.
You must be one of the few ones. According to the RFC's, you should quote
pretty much any punctuation mark, including "." itself. Which means that
things like
Signed-off-by: David S. Miller <davem@davemloft.net>
should be quoted if they were email addresses.
That would be very irritating.
It's even _more_ irritating for things like D'Souza (or Giuseppe D'Eliseo
to take a real example from the kernel). For David, we could just not use
the "S." - for others, the special characters are very much part of the
name. It would also be very irritating for important messages like
Signed-off-by: Linus "I'm a moron" Torvalds <torvalds@osdl.org>
etc, where it sure as heck isn't a rfc2822-compliant email address.
So the thing is, "strict email format" is just very annoying. Git does
know how to do (well, it _should_) it for "git send-email", but making the
human-readable output ugly just because somebody might want to
cut-and-paste it sounds really sad.
You could cut-and-paste just the stuff inside the angle branckets, though.
That should work.
Linus
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 22:27 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, torvalds, git
In-Reply-To: <20080801221539.GA8617@mit.edu>
On Fri, 1 Aug 2008 18:15:39 -0400 Theodore Tso <tytso@mit.edu> wrote:
> How about this as a compromise? Git continues to store the names in
> its internal format as it always does, but there is a configuration
> option which controls whether the various Author: and Committer:
> fields when displayd by git-log are in RFC-822 format or not.
Well I believe/expect/hope that git's name+email-address transformation
goes via a lookup in the kernel's .mailmap file.
And the existing .mailmap appears to have taken care that all the
"name" parts are in an MUA-usable form. There are no periods or
commas.
So if everyone had a .mailmap entry then
- The Author: lines would all be MUA usable
- The Author lines would all be in their owners' preferred form. I mean,
converting
"Morton, Andrew"
into
Morton, Andrew
didn't improve things much.
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 22:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <20080801152720.56dbff09.akpm@linux-foundation.org>
On Fri, 1 Aug 2008, Andrew Morton wrote:
>
> And the existing .mailmap appears to have taken care that all the
> "name" parts are in an MUA-usable form. There are no periods or
> commas.
Umm. Or quotes? I don't think so. Or even periods? You must not have
looked at things, I found one at the very first screenful.
Ed L. Cashin <ecashin@coraid.com>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
S.Çağlar Onur <caglar@pardus.org.tr>
adn that's just basically ignoring the fact that we only add mailmap
entries for people who can't get it right other ways (where admittedly
sometimes the "can't get it right" comes from the people in between: poor
Çağlar has had his name corrupted so many times that it's funny).
Linus
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 22:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <20080801152720.56dbff09.akpm@linux-foundation.org>
Btw, the real issue here is
- why do you want to make things uglier and make up stupid rules that are
irrelevant to git, just for something that you admit you hadn't ever
even _noticed_ until now, and now that you know about it it's not even
a problem any more?
especially as
- we know people won't do the quoting _anyway_, since we actually have
tons of examples of that in the kernel as-is.
Quoting should be for _tools_, not for people. And even if we did it, we
probably wouldn't be fully rfc2822-compliant anyway, because anybody sane
would decide to not quote '@' and '.', rigth?
Because those don't actually really have special meaning (yeah, they are
"special" characters in rfc-2822, but nobody cares, and the MUA can do it
for us, no)?
So now we'd actually not really be rfc-compliant _anyway_, because
everybody really realizes just how annoying that would really be.
Linus
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 22:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.1.10.0808011507430.6819@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008 15:23:23 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 1 Aug 2008, Andrew Morton wrote:
> >
> > I preserve the quotes (when present) in signoffs for this exact reason.
>
> You must be one of the few ones.
Not the only one. See d67d1c7bf948341fd8678c8e337ec27f4b46b206,
3bf2e77453a87c22eb57ed4926760ac131c84459, ...
> According to the RFC's, you should quote
> pretty much any punctuation mark, including "." itself. Which means that
> things like
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> should be quoted if they were email addresses.
>
> That would be very irritating.
Yeah, it's ugly as sin. But it has usability benefits. Few people
actually need this treatment.
> It's even _more_ irritating for things like D'Souza (or Giuseppe D'Eliseo
> to take a real example from the kernel). For David, we could just not use
> the "S." - for others, the special characters are very much part of the
> name. It would also be very irritating for important messages like
>
> Signed-off-by: Linus "I'm a moron" Torvalds <torvalds@osdl.org>
>
> etc, where it sure as heck isn't a rfc2822-compliant email address.
It might be. Look at this guy:
From: Josef "Jeff" Sipek <jsipek@cs.sunysb.edu>
Who later did an edit and became
From: "Josef 'Jeff' Sipek" <jsipek@cs.sunysb.edu>
> So the thing is, "strict email format" is just very annoying. Git does
> know how to do (well, it _should_) it for "git send-email", but making the
> human-readable output ugly just because somebody might want to
> cut-and-paste it sounds really sad.
It didn't make human-readable output ugly. It was already ugly and it
just left it alone so it was still usable.
> You could cut-and-paste just the stuff inside the angle branckets, though.
> That should work.
Sure. I like to include people's names though.
Perhaps a suitable solution to all this would be to teach more things
to use .mailmap transformations and to update that file more.
otoh, if people really want to present themselves to the world in a
name-reversed, comma-stuffed, quote-wrapped form then that was their
choice..
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 22:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <alpine.LFD.1.10.0808011531290.6819@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008 15:34:16 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 1 Aug 2008, Andrew Morton wrote:
> >
> > And the existing .mailmap appears to have taken care that all the
> > "name" parts are in an MUA-usable form. There are no periods or
> > commas.
>
> Umm. Or quotes? I don't think so. Or even periods? You must not have
> looked at things, I found one at the very first screenful.
>
> Ed L. Cashin <ecashin@coraid.com>
> Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
> S.__a__lar Onur <caglar@pardus.org.tr>
oh. So .mailmap isn't usable either. Argh.
I guess it'd be fairly simple to slap quotes around anything which
contains fishy characters.
> adn that's just basically ignoring the fact that we only add mailmap
> entries for people who can't get it right other ways (where admittedly
> sometimes the "can't get it right" comes from the people in between: poor
> __a__lar has had his name corrupted so many times that it's funny).
^^^^^^^^ (lol)
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 22:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <alpine.LFD.1.10.0808011534260.6819@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008 15:39:37 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> Btw, the real issue here is
>
> - why do you want to make things uglier and make up stupid rules that are
> irrelevant to git, just for something that you admit you hadn't ever
> even _noticed_ until now, and now that you know about it it's not even
> a problem any more?
None of that is correct.
The real issue here is:
- Why do you want to take usable RFC-compliant email addresses and
mangle them in a manner which still doesn't match the person's
actual name and which makes unsuspecting users of git potentially
lose important email communications?
Ain't framing great?
> especially as
>
> - we know people won't do the quoting _anyway_, since we actually have
> tons of examples of that in the kernel as-is.
>
> Quoting should be for _tools_, not for people. And even if we did it, we
> probably wouldn't be fully rfc2822-compliant anyway, because anybody sane
> would decide to not quote '@' and '.', rigth?
>
> Because those don't actually really have special meaning (yeah, they are
> "special" characters in rfc-2822, but nobody cares, and the MUA can do it
> for us, no)?
>
> So now we'd actually not really be rfc-compliant _anyway_, because
> everybody really realizes just how annoying that would really be.
>
Linus, just admit it: copying and pasting from git-log output into the MUA
is *useful*. And you've made it less reliable.
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 22:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <alpine.LFD.1.10.0808011531290.6819@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008, Linus Torvalds wrote:
>
> S.Çağlar Onur <caglar@pardus.org.tr>
Btw, poor guy is _really_ screwed. He'd show up as
"=?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur" <caglar@pardus.org.tr>
which must really hurt.
Can you not see how STUPID it would be to say that the name should be
shown as an email encoding requires it?
Really. Just admit that you were wrong. The fact is, asking for rfc2822
encoding in logs etc is a HORRIBLY HORRIBLY stupid thing to do.
What you really want was just something you could cut-and-paste into your
mailer. Which actually means that the only special character is probably
",", and your claims of how bad the design was that it didn't leave the
total mess that rfc2822 is was actually not true, and was based on simply
not knowing how nasty the real world is...
Quote frankly, If I had one of the Finnish special characters in my name,
I'd piss on your grave if you suggested that. Try to guess what something
like
=?ISO-8859-15?Q?Linus_T=F6rnqvist?= <torvalds@linux-foundation.org>
is supposed to be.
Linus
^ permalink raw reply
* extracting to/cc addresses for stg mail
From: Bjorn Helgaas @ 2008-08-01 22:50 UTC (permalink / raw)
To: git
I'm new to stg, so maybe I'm missing the easy way to do this.
That said, I'd like to maintain "To:" fields in the patch
description, like this:
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
"stg mail --auto" takes care of adding Andrew to the Cc list,
but I have to manually deal with Andi.
I've been doing that by using "stg mail --auto -E" and manually
moving the To: line to the top, but that's a hassle. I don't
really want to use "stg mail --to=", because then I have to dig
out the To: line contents first. I don't really want to use
different template files, because I often have one-off self-
contained patches that go different places.
Is there a way to make stg pay attention to my "To:" lines in
the patch description? Or another way to accomplish this?
Bjorn
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 22:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <20080801154453.921bb50f.akpm@linux-foundation.org>
On Fri, 1 Aug 2008, Andrew Morton wrote:
> > S.__a__lar Onur <caglar@pardus.org.tr>
>
> oh. So .mailmap isn't usable either. Argh.
Btw, your mailer really is broken. It seems to have turned my correct
utf-8 email into US-ASCII.
Or at least it was correct when it came back to me. I don't see the
corruption. But your mailer seems to be unable to handle any complex
character sets and did
X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
and I wonder why?
Yeah, I feel superior, because alpine actually gets things right these
days. I too used to be character-set-confused.
Linus
^ 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