* Re: [PATCH] diff: add ruby funcname pattern
From: Junio C Hamano @ 2008-08-02 3:50 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Giuseppe Bilotta, git
In-Reply-To: <0C57339C-50EF-4199-A14B-AFF04C92EF87@sb.org>
Kevin Ballard <kevin@sb.org> writes:
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>> ...
>>> I wasn't sure about the completeness of the regexp myself, which is
>> ...
> As a Ruby user, the regex for the funcname looks fine to me.
Thanks, will apply.
^ permalink raw reply
* PHP購物車資料庫網站專案
From: 陳友中 @ 2008-08-02 3:00 UTC (permalink / raw)
To: gitmonth
山鉧科技網頁設計
我們的宗旨：客戶的每ㄧ件小事情，都是山鉧的大事情
我們在推出企業形象網站包含前台網頁美工+後台管理程式
限時限量專案價 只要$29,900
(在送ㄧ年100MB不限流量網站空間)
我們做的不只是網站，而是您企業的入口
ㄧ個好的企業網站資料即時更新的速度是很重要的
企業ｅ化的高品質團隊，打造您的網路門面
選擇山鉧成就您的夢想
～～～～～～～～～～～～～～～～～～～～～～～～～～
PS: 線上購物網站我們還可提供刷卡機制，
與線上列印帳單全省超商+郵局繳費......等金流服務機制
～～～～～～～～～～～～～～～～～～～～～～～～～～
歡迎來電洽詢黃專員（Sam）：0980119812 / 0938764395
上網搜尋『 山鉧科技公司網站 』即可找到我們
～～～～～～～～～～～～～～～～～～～～～～～～～～
本公司另外提供關鍵字SEO排序服務
保證將您的網站在Yx / Gx ...排在第一頁
歡迎來電詢問!!!
～～～～～～～～～～～～～～～～～～～～～～～～～～
^ permalink raw reply
* [PATCH] builtin-revert.c: typofix
From: Stephan Beyer @ 2008-08-02 1:51 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, gitster, Stephan Beyer
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
builtin-revert.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index e9da870..27881e9 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -180,7 +180,7 @@ static void set_author_ident_env(const char *message)
email++;
timestamp = strchr(email, '>');
if (!timestamp)
- die ("Could not extract author email from %s",
+ die ("Could not extract author time from %s",
sha1_to_hex(commit->object.sha1));
*timestamp = '\0';
for (timestamp++; *timestamp && isspace(*timestamp);
--
1.6.0.rc0.49.gd39f
^ permalink raw reply related
* [PATCH] bash completion: Add more long options for 'git log'
From: Lee Marlow @ 2008-08-02 0:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
Options added: --parents --children --full-history
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 30d8701..7132a68 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -853,6 +853,7 @@ _git_log ()
--stat --numstat --shortstat
--decorate --diff-filter=
--color-words --walk-reflogs
+ --parents --children --full-history
"
return
;;
--
1.6.0.rc1.27.g9b6bf
^ permalink raw reply related
* [PATCH] bash completion: Add completion for 'git grep'
From: Lee Marlow @ 2008-08-02 0:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
Added completions for all long options specified in the docs
--cached
--text --ignore-case --word-regexp --invert-match
--full-name
--extended-regexp --basic-regexp --fixed-strings
--files-with-matches --name-only
--files-without-match
--count
--and --or --not --all-match
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 30d8701..b28ac10 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -796,6 +796,29 @@ _git_gc ()
COMPREPLY=()
}
+_git_grep ()
+{
+ __git_has_doubledash && return
+
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "
+ --cached
+ --text --ignore-case --word-regexp --invert-match
+ --full-name
+ --extended-regexp --basic-regexp --fixed-strings
+ --files-with-matches --name-only
+ --files-without-match
+ --count
+ --and --or --not --all-match
+ "
+ return
+ ;;
+ esac
+ COMPREPLY=()
+}
+
_git_help ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
@@ -1486,6 +1509,7 @@ _git ()
fetch) _git_fetch ;;
format-patch) _git_format_patch ;;
gc) _git_gc ;;
+ grep) _git_grep ;;
help) _git_help ;;
log) _git_log ;;
ls-remote) _git_ls_remote ;;
--
1.6.0.rc1.27.g9b6bf
^ permalink raw reply related
* Re: [PATCH] diff: add ruby funcname pattern
From: Kevin Ballard @ 2008-08-02 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git
In-Reply-To: <7v4p65tadh.fsf@gitster.siamese.dyndns.org>
On Aug 1, 2008, at 1:20 AM, Junio C Hamano wrote:
> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>
>> On Fri, Aug 1, 2008 at 9:30 AM, Junio C Hamano <gitster@pobox.com>
>> wrote:
>> ...
>>> so I'll wait for a few days to hear any one of the
>>> following happen before deciding what to do with this patch:
>>>
>>> (1) Yeah, this is a sufficient and necessary set of keywords, and it
>>> would make my Ruby life so much better;
>>>
>>> (2) This might be a good start but you need to cover this and that
>>> keywords as well;
>>>
>>> (3) This will misidentify a line that is not the beginning of a
>>> definition, and should not be applied;
>>>
>>> Needless to say, "Here is a better patch" is appreciated if
>>> somebody says
>>> (2) or (3).
>>
>> I wasn't sure about the completeness of the regexp myself, which is
>
> Well, I forgot to say but the above was soliciting third party review;
> original submitter does not count ;-)
>
> ... nah, I am just joking.
>
> All of the things you said in the message I am responding to are good
> background information. It would have been nicer if it were part of
> the
> initial message, perhaps below the three dash lines, which would have
> avoided this extra exchange.
As a Ruby user, the regex for the funcname looks fine to me.
> Thanks again for the patch. Somewhere I heard that there are 10
> Rubyista
> git users for every non Rubyista git user, so I am sure somebody would
> comment on your patch in a day or two. Perhaps we might even get
> Python
> and Perl hunk patterns (although I suspect Perl people are happy
> with the
> default one we stole from GNU diff) to go with it ;-).
I'd like to point out that Python users are called Pythonistas, Ruby
users are called... uh, Ruby users, I guess.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 23:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <alpine.LFD.1.10.0808011554350.6819@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008, Linus Torvalds wrote:
>
> That's my argument here. Life is tough. Not everthing is going to be
> easy. Your solution would "work", but it would be a horrid piece of crap.
..and I really think that the
"=?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur" <caglar@pardus.org.tr>
example should be the one that makes you say "Ok, you're right".
The undeniable fact is, if we kept things in that format, even your broken
mailer wouldn't have corrupted it. You could cut-and-paste things, and
they's show up correctly at the other end, regardless of whether the
problem is with your mailer or with the cut-and-paste, or anything else.
So clearly, "=?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur" _must_ be the superior
format that git should have used, no?
Because clearly that is the most automation-friendly thing that _never_
requires anybody to think at all, and you can cut-and-paste it between
programs without ever having to worry about anything at all. No special
characters, no special meanings, no need to worry about limitations of
implementation.
So the fact that git completely FUCKS IT UP, and when you do 'git log' git
will have corrupted this to
Author: S.Çağlar Onur <caglar@pardus.org.tr>
is clearly git doing the wrong thing. Right?
WRONG.
The fact is, git does the right thing. And yes, it means that you cannot
just blindly cut-and-paste. And yes, it means that your mailer actually
has to work right for you to even -see- the right email address. And yes,
it means that any number of things can screw up, and corrupt it.
But it is STILL the right thing. Because what matters more than your
ability to cut-and-paste or anything like that is the fact that we should
make things look sane.
The thing is, you can actually get git to output the crazy names. Just do
git show --pretty=email 37a4c940749670671adab211a2d9c9fed9f3f757
and now you get the email-prettified thing for at least the author. No,
git won't corrupt the actual message, so the Signed-off-by: lines will
still show Çağlar's first name, but you can actually get back that odd
format.
(In fact, --pretty=email will do it as
From: =?utf-8?q?S.=C3=87a=C4=9Flar=20Onur?= <caglar@pardus.org.tr>
which is admittedy _even_uglier_, but whatever.. The difference between
really f*cking ugly and really f*cking uglier is not really relevant).
Linus
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Dmitry Potapov @ 2008-08-01 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git, Eric Wong
In-Reply-To: <7vr698qt6w.fsf@gitster.siamese.dyndns.org>
On Fri, Aug 01, 2008 at 03:14:15PM -0700, Junio C Hamano wrote:
>
> 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.
Here it goes. It turned out that there are only two places that actually
needs correction, while two others use '0'. I have run 'make test' and
it's passed the tests.
-- 8< --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Sat, 2 Aug 2008 02:56:45 +0400
Subject: [PATCH] convert index_path callers to use bitmask instead of 1
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
builtin-update-index.c | 5 +++--
read-cache.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 38eb53c..d3e212c 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -85,7 +85,7 @@ static int process_lstat_error(const char *path, int err)
static int add_one_path(struct cache_entry *old, const char *path, int len, struct stat *st)
{
- int option, size;
+ int option, flags, size;
struct cache_entry *ce;
/* Was the old index entry already up-to-date? */
@@ -99,7 +99,8 @@ static int add_one_path(struct cache_entry *old, const char *path, int len, stru
fill_stat_cache_info(ce, st);
ce->ce_mode = ce_mode_from_stat(old, st->st_mode);
- if (index_path(ce->sha1, path, st, !info_only))
+ flags = info_only ? 0 : HASH_OBJECT_DO_CREATE;
+ if (index_path(ce->sha1, path, st, flags))
return -1;
option = allow_add ? ADD_CACHE_OK_TO_ADD : 0;
option |= allow_replace ? ADD_CACHE_OK_TO_REPLACE : 0;
diff --git a/read-cache.c b/read-cache.c
index 2c03ec3..afd6005 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -550,7 +550,7 @@ int add_to_index(struct index_state *istate, const char *path, struct stat *st,
alias->ce_flags |= CE_ADDED;
return 0;
}
- if (index_path(ce->sha1, path, st, 1))
+ if (index_path(ce->sha1, path, st, HASH_OBJECT_DO_CREATE))
return error("unable to index file %s", path);
if (ignore_case && alias && different_name(ce, alias))
ce = create_alias_ce(ce, alias);
--
1.6.0.rc1.34.gad373
^ permalink raw reply related
* Re: email address handling
From: Andrew Morton @ 2008-08-01 23:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <alpine.LFD.1.10.0808011550450.6819@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008 15:52:36 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> 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.
>
sylpheed. If you use its internal editor it mostly gets things right.
But if you use its use-external-editor feature it messes up those
things when saving out to its temporary file. And it was written by a
Japanese guy.
I'll often fix it in changelogs by re-editing the changelog and doing
a copy-n-paste from sylpheed's display window into the editor, which
does work. All a bit of a pain though.
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 22:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <20080801154902.c60717e5.akpm@linux-foundation.org>
On Fri, 1 Aug 2008, Andrew Morton wrote:
>
> Linus, just admit it: copying and pasting from git-log output into the MUA
> is *useful*. And you've made it less reliable.
Oh, I admit it is useful.
But your "solution" is actually MUCH MUCH MUCH worse than what git does.
That's my argument here. Life is tough. Not everthing is going to be
easy. Your solution would "work", but it would be a horrid piece of crap.
Linus
^ 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
* 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: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
* 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: 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: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: 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: 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: 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: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
* [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
* [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
* 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
* 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: [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