* Re: email address handling
From: Linus Torvalds @ 2008-08-01 19:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20080801124550.26b9efc0.akpm@linux-foundation.org>
On Fri, 1 Aug 2008, Andrew Morton wrote:
>
> That's how I noticed it - copied, pasted, MTA barfed.
>
> Converting a usable name+email-address into an unusable one seems ... unuseful.
Umm. Those signed-off ones weren't even _converted_ They were written by
people.
Also, you seemed to miss the point that it's not a name+email-address.
It's a name. Oh, and there's an email address too. But they aren't
connected. We often just print out the name *without* the email address.
Why should those things have to know about some totally irrelevant email
quoting rules? They weren't emails, didn't know about it, and didn't care.
Linus
^ permalink raw reply
* Re: email address handling
From: Junio C Hamano @ 2008-08-01 20:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, git
In-Reply-To: <20080801124550.26b9efc0.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> On Fri, 1 Aug 2008 12:34:58 -0700 (PDT)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> And Andrew, this is true of Signed-off-by: lines too, btw. If you actually
>> want to send emails to them, _then_ you need to add quotes to follow the
>> email rules.
>
> That's how I noticed it - copied, pasted, MTA barfed.
>
> Converting a usable name+email-address into an unusable one seems ... unuseful.
Name is used not just for pasting into your MUA. For example, if your
shortlog output showed this, it would be "funny looking":
"Zhang, Rui" (4):
...
Andrew Morton (20):
...
...
^ permalink raw reply
* [PATCH] Add Pascal/Delphi (.pas file) funcname pattern.
From: Avery Pennarun @ 2008-08-01 19:45 UTC (permalink / raw)
To: gitster, git; +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>
---
The Ruby funcname pattern patch inspired me. Although unlike him, I didn't
check with anyone else for confirmation. How many Pascal programmers can
there possibly be? :)
diff.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index cbf2547..c73ba69 100644
--- a/diff.c
+++ b/diff.c
@@ -1380,6 +1380,10 @@ static struct builtin_funcname_pattern {
"^[ ]*\\(\\([ ]*"
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
"[ ]*([^;]*\\)$" },
+ { "pas", "\\(^\\(procedure\\|function\\|constructor\\|"
+ "destructor\\|interface\\|implementation\\|"
+ "type|initialization|finalization\\).*$\\)"
+ "\\|\\(^.*=[ \t]*\\(class\\|record\\).*$\\)" },
{ "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
};
--
1.6.0.rc1.34.g23b24.dirty
^ permalink raw reply related
* Re: email address handling
From: Junio C Hamano @ 2008-08-01 20:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, git
In-Reply-To: <alpine.LFD.1.10.0808011253580.3277@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Fri, 1 Aug 2008, Andrew Morton wrote:
>>
>> That's how I noticed it - copied, pasted, MTA barfed.
>>
>> Converting a usable name+email-address into an unusable one seems ... unuseful.
>
> Umm. Those signed-off ones weren't even _converted_ They were written by
> people.
>
> Also, you seemed to miss the point that it's not a name+email-address.
>
> It's a name. Oh, and there's an email address too. But they aren't
> connected. We often just print out the name *without* the email address.
> Why should those things have to know about some totally irrelevant email
> quoting rules? They weren't emails, didn't know about it, and didn't care.
One place that can matter is git-send-email.perl; IIRC, it reads from the
S-o-b:, Cc: and From: lines people write, and these follow "name next to
address, that does not care irrelevant email quoting rules" format. I do
not think send-email currently does much about quoting them, but I think
it should be the right place to do so.
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 20:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0808011253580.3277@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008 12:56:44 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 1 Aug 2008, Andrew Morton wrote:
> >
> > That's how I noticed it - copied, pasted, MTA barfed.
> >
> > Converting a usable name+email-address into an unusable one seems ... unuseful.
>
> Umm. Those signed-off ones weren't even _converted_ They were written by
> people.
This was the Author: line.
Afaik that person doesn't send patches via git, and that this text by
some means was transferred into git from an emailed patch.
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.
> Also, you seemed to miss the point that it's not a name+email-address.
I know exactly what it is.
> It's a name. Oh, and there's an email address too. But they aren't
> connected. We often just print out the name *without* the email address.
> Why should those things have to know about some totally irrelevant email
> quoting rules? They weren't emails, didn't know about it, and didn't care.
Well, as I said, it's a minor point. It's just that converting
something which _can_ be copied and pasted into an MUA into something
which cannot seems... odd.
Most sane MUA's will omit the quotes if the name part does not need
them, so simply retaining the quotes if they were originally there
would be an OK thing to do.
So how serious is this issue?
Well, if all MUAs either generate synchronous error messages or will
insert the quotes for you then not very serious at all.
If, however, there are MUA+MTA combinations which do _not_ inform about
or correct the error then this failure to quote the name could cause
people's emails to get lost altogether, which is a bit serious.
Also, _most_ git Author: lines _can_ be successfully copied-and-pasted
into an MUA. The fact that a small minority of git Author: lines cannot
be used this way is a bit dangerous.
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 20:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, git
In-Reply-To: <7viquksdyn.fsf@gitster.siamese.dyndns.org>
On Fri, 01 Aug 2008 13:00:16 -0700
Junio C Hamano <gitster@pobox.com> wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
> > On Fri, 1 Aug 2008 12:34:58 -0700 (PDT)
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> >> And Andrew, this is true of Signed-off-by: lines too, btw. If you actually
> >> want to send emails to them, _then_ you need to add quotes to follow the
> >> email rules.
> >
> > That's how I noticed it - copied, pasted, MTA barfed.
> >
> > Converting a usable name+email-address into an unusable one seems ... unuseful.
>
> Name is used not just for pasting into your MUA. For example, if your
> shortlog output showed this, it would be "funny looking":
>
> "Zhang, Rui" (4):
> ...
>
> Andrew Morton (20):
> ...
> ...
yep. That'd be a git-shortlog bug :)
I really don't care about this much!
^ permalink raw reply
* Re: [PATCH] Add Pascal/Delphi (.pas file) funcname pattern.
From: Junio C Hamano @ 2008-08-01 20:16 UTC (permalink / raw)
To: Avery Pennarun; +Cc: gitster, git
In-Reply-To: <1217619915-9331-1-git-send-email-apenwarr@gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> 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>
> ---
>
> The Ruby funcname pattern patch inspired me. Although unlike him, I didn't
> check with anyone else for confirmation. How many Pascal programmers can
> there possibly be? :)
> + { "pas", "\\(^\\(procedure\\|function\\|constructor\\|"
> + "destructor\\|interface\\|implementation\\|"
> + "type|initialization|finalization\\).*$\\)"
> + "\\|\\(^.*=[ \t]*\\(class\\|record\\).*$\\)" },
Is Delphi the only surviving Pascal? Why is the name "pas", not "pascal"
or even "delphi-pascal"?
The keys are not file extensions ("ruby" example did the right thing by
not saying "rb").
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 20:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20080801131127.20b3acfd.akpm@linux-foundation.org>
On Fri, 1 Aug 2008, Andrew Morton wrote:
>
> This was the Author: line.
So?
I mean, it's not sending email, is it? It says "Author:".
You could have just inserted the actual email address. Or something.
Linus
^ permalink raw reply
* Re: [PATCH] Add Pascal/Delphi (.pas file) funcname pattern.
From: Petr Baudis @ 2008-08-01 20:20 UTC (permalink / raw)
To: Avery Pennarun; +Cc: gitster, git
In-Reply-To: <1217619915-9331-1-git-send-email-apenwarr@gmail.com>
On Fri, Aug 01, 2008 at 03:45:15PM -0400, Avery Pennarun wrote:
> diff --git a/diff.c b/diff.c
> index cbf2547..c73ba69 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1380,6 +1380,10 @@ static struct builtin_funcname_pattern {
> "^[ ]*\\(\\([ ]*"
> "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
> "[ ]*([^;]*\\)$" },
> + { "pas", "\\(^\\(procedure\\|function\\|constructor\\|"
> + "destructor\\|interface\\|implementation\\|"
> + "type|initialization|finalization\\).*$\\)"
> + "\\|\\(^.*=[ \t]*\\(class\\|record\\).*$\\)" },
> { "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
> };
>
Wouldn't it be better to make the second pattern start on new line
instead of the outer \(\|\)?
Why "type"?
--
Petr "Pasky, but not writing in Pascal anymore!" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 20:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0808011316050.3277@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008 13:17:11 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 1 Aug 2008, Andrew Morton wrote:
> >
> > This was the Author: line.
>
> So?
So all the other things I said.
> I mean, it's not sending email, is it? It says "Author:".
>
> You could have just inserted the actual email address. Or something.
>
pls read earlier email.
^ permalink raw reply
* git-submodule add -b
From: Tim Olsen @ 2008-08-01 20:27 UTC (permalink / raw)
To: git
The git-submodule man page says that the -b option to "git-submodule
add" is the "Branch of repository to add as submodule."
I get the error "fatal: A branch named '1.x' already exists." when I try
to use "git submodule add -b". A sample session is below. What am I
doing wrong?
tolsen@neurofunk:~/git$ mkdir submodule-branch
tolsen@neurofunk:~/git$ cd submodule-branch
tolsen@neurofunk:~/git/submodule-branch$ mkdir sub
tolsen@neurofunk:~/git/submodule-branch$ cd sub
tolsen@neurofunk:~/git/submodule-branch/sub$ git init
Initialized empty Git repository in
/home/tolsen/git/submodule-branch/sub/.git/
tolsen@neurofunk:~/git/submodule-branch/sub$ echo 1 > file
tolsen@neurofunk:~/git/submodule-branch/sub$ git add file
tolsen@neurofunk:~/git/submodule-branch/sub$ git commit -m v1
Created initial commit d5c185a: v1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file
tolsen@neurofunk:~/git/submodule-branch/sub$ echo 2 > file
tolsen@neurofunk:~/git/submodule-branch/sub$ git add file
tolsen@neurofunk:~/git/submodule-branch/sub$ git commit -m v2
Created commit fb864b2: v2
1 files changed, 1 insertions(+), 1 deletions(-)
tolsen@neurofunk:~/git/submodule-branch/sub$ git log
commit fb864b2d4d9dacd87e55d0be970baa5fc6a0972c
Author: Tim Olsen <tolsen@limespot.com>
Date: Fri Aug 1 16:21:09 2008 -0400
v2
commit d5c185a7ea91b66b5df524b21bbe0daf40a456f4
Author: Tim Olsen <tolsen@limespot.com>
Date: Fri Aug 1 16:21:03 2008 -0400
v1
tolsen@neurofunk:~/git/submodule-branch/sub$ git checkout -b 1.x d5c185a7
Switched to a new branch "1.x"
tolsen@neurofunk:~/git/submodule-branch/sub$ echo 1.1 > file
tolsen@neurofunk:~/git/submodule-branch/sub$ git add file
tolsen@neurofunk:~/git/submodule-branch/sub$ git commit -m v1.1
Created commit d9868c5: v1.1
1 files changed, 1 insertions(+), 1 deletions(-)
tolsen@neurofunk:~/git/submodule-branch/sub$ git log
commit d9868c5dc837404834b44eca6d21930c4f352127
Author: Tim Olsen <tolsen@limespot.com>
Date: Fri Aug 1 16:21:58 2008 -0400
v1.1
commit d5c185a7ea91b66b5df524b21bbe0daf40a456f4
Author: Tim Olsen <tolsen@limespot.com>
Date: Fri Aug 1 16:21:03 2008 -0400
v1
tolsen@neurofunk:~/git/submodule-branch/sub$ cd ..
tolsen@neurofunk:~/git/submodule-branch$ mkdir super
tolsen@neurofunk:~/git/submodule-branch$ cd super
tolsen@neurofunk:~/git/submodule-branch/super$ git init
Initialized empty Git repository in
/home/tolsen/git/submodule-branch/super/.git/
tolsen@neurofunk:~/git/submodule-branch/super$ echo dummy > dummy
tolsen@neurofunk:~/git/submodule-branch/super$ git add dummy
tolsen@neurofunk:~/git/submodule-branch/super$ git commit -m dummy
Created initial commit f1c41b6: dummy
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 dummy
tolsen@neurofunk:~/git/submodule-branch/super$ cd ..
tolsen@neurofunk:~/git/submodule-branch$ git clone super super2
Initialized empty Git repository in
/home/tolsen/git/submodule-branch/super2/.git/
tolsen@neurofunk:~/git/submodule-branch$ cd super2
tolsen@neurofunk:~/git/submodule-branch/super2$ git submodule add -b 1.x
~/git/submodule-branch/sub
Initialized empty Git repository in
/home/tolsen/git/submodule-branch/super2/sub/.git/
fatal: A branch named '1.x' already exists.
Unable to checkout submodule 'sub'
tolsen@neurofunk:~/git/submodule-branch/super2$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# sub/
nothing added to commit but untracked files present (use "git add" to track)
tolsen@neurofunk:~/git/submodule-branch/super2$
Thanks,
Tim
^ permalink raw reply
* [PATCH] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-08-01 20:35 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Giuseppe Bilotta
In-Reply-To: <1217593425-28314-1-git-send-email-giuseppe.bilotta@gmail.com>
When using path info, make filenames start with a / (right after the :
that separates them from the hash base). This minimal change allows
relative navigation to work properly when viewing HTML files.
---
This patch is based on top of my previous patch
gitweb: action in path with use_pathinfo
(which I sent with the wrong CC: lines)
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 56fbdab..a8c0887 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -664,7 +664,7 @@ sub href (%) {
if (defined $params{'hash_base'}) {
$href .= "/".esc_url($params{'hash_base'});
if (defined $params{'file_name'}) {
- $href .= ":".esc_url($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'});
delete $params{'file_name'};
} else {
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH] Add Pascal/Delphi (.pas file) funcname pattern.
From: Avery Pennarun @ 2008-08-01 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wvgsd6s.fsf@gitster.siamese.dyndns.org>
On 8/1/08, Junio C Hamano <gitster@pobox.com> wrote:
> Is Delphi the only surviving Pascal? Why is the name "pas", not "pascal"
> or even "delphi-pascal"?
No, but all surviving Pascals pretty much support the same syntax, so
when I say Pascal/Delphi, I mean either one. And Delphi does use the
.pas extension.
> The keys are not file extensions ("ruby" example did the right thing by
> not saying "rb").
Will fix.
Avery
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 20:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20080801132415.0b0314e4.akpm@linux-foundation.org>
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.
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.
Linus
^ permalink raw reply
* 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
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