* What's cooking in git.git (Jan 2009, #03; Wed, 14)
@ 2009-01-14 11:32 Junio C Hamano
2009-01-15 19:49 ` Kirill Smelkov
0 siblings, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2009-01-14 11:32 UTC (permalink / raw
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The ones marked with '.' do not appear in any of
the branches, but I am still holding onto them.
The topics list the commits in reverse chronological order. The
topics meant to be merged to the maintenance series have "maint-"
in their names.
----------------------------------------------------------------
[New Topics]
* kb/am-directory (Sun Jan 11 22:21:48 2009 -0800) 1 commit
+ git-am: add --directory=<dir> option
This is "third-time-lucky, perhaps?" resurrection. I do not think I'd be
using this very often, but it originated from a real user request.
* jk/signal-cleanup (Sun Jan 11 06:36:49 2009 -0500) 3 commits
- pager: do wait_for_pager on signal death
- refactor signal handling for cleanup functions
- chain kill signals for cleanup functions
* kb/lstat-cache (Tue Jan 13 13:29:08 2009 +0100) 5 commits
- lstat_cache(): introduce clear_lstat_cache() function
- lstat_cache(): introduce invalidate_lstat_cache() function
- lstat_cache(): introduce has_dirs_only_path() function
- lstat_cache(): introduce has_symlink_or_noent_leading_path()
function
- lstat_cache(): more cache effective symlink/directory detection
This is the seventh round; although the author asked me not to bother, I
couldn't resist. I renamed one helper function while reading the patches
and made minor adjustments on styles, but it looked reasonable.
* lh/submodule-tree-traversal (Mon Jan 12 00:45:55 2009 +0100) 3 commits
- builtin-ls-tree: enable traversal of submodules
- archive.c: enable traversal of submodules
- tree.c: add support for traversal of submodules
* jc/maint-format-patch-o-relative (Mon Jan 12 15:18:02 2009 -0800) 1 commit
- Teach format-patch to handle output directory relative to cwd
This was my lunchtime "this may fix it" response to a breakage report. I
haven't really thought things through but my gut feeling is this might
break things for minorities who are accustomed to the existing behaviour,
especially wrt the filenames reported on the standard output.
* lt/maint-wrap-zlib (Wed Jan 7 19:54:47 2009 -0800) 1 commit
+ Wrap inflate and other zlib routines for better error reporting
Needs the "free our memory upon seeing Z_MEM_ERROR and try again" bits
extracted from Shawn's patch on top of this one.
* js/diff-color-words (Sun Jan 11 21:00:58 2009 +0100) 4 commits
- color-words: take an optional regular expression describing words
- color-words: refactor to allow for 0-character word boundaries
- color-words: refactor word splitting and use ALLOC_GROW()
- Add color_fwrite(), a function coloring each line individually
Dscho's series that was done in response to Thomas's original; two agreed
to work together on this codebase.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
. autoconf: Enable threaded delta search when pthreads are supported
I haven't heard neither positive nor negative comments from minority
platforms that might be harmed, but this feels like the right thing to do,
so perhaps the best course of action is to merge this down to 'master' and
see if anybody screams.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
----------------------------------------------------------------
[Actively cooking]
* gb/gitweb-opml (Fri Jan 2 13:49:30 2009 +0100) 2 commits
+ gitweb: suggest name for OPML view
+ gitweb: don't use pathinfo for global actions
* ks/maint-mailinfo-folded (Mon Jan 12 15:22:11 2009 -0800) 2 commits
- mailinfo: 'From:' header should be unfold as well
- mailinfo: correctly handle multiline 'Subject:' header
The author seems to have more updates, but I couldn't extract them from
the e-mail.
* js/patience-diff (Thu Jan 1 17:39:37 2009 +0100) 3 commits
+ bash completions: Add the --patience option
+ Introduce the diff option '--patience'
+ Implement the patience diff algorithm
* mv/apply-parse-opt (Fri Jan 9 22:21:36 2009 -0800) 2 commits
+ Resurrect "git apply --flags -" to read from the standard input
+ parse-opt: migrate builtin-apply.
* tr/rebase-root (Fri Jan 2 23:28:29 2009 +0100) 4 commits
+ rebase: update documentation for --root
+ rebase -i: learn to rebase root commit
+ rebase: learn to rebase root commit
+ rebase -i: execute hook only after argument checking
Looked reasonable.
* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
+ git-notes: fix printing of multi-line notes
+ notes: fix core.notesRef documentation
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
----------------------------------------------------------------
[Graduated to "master"]
* nd/grep-assume-unchanged (Sat Dec 27 15:21:03 2008 +0700) 2 commits
+ grep: grep cache entries if they are "assume unchanged"
+ grep: support --no-ext-grep to test builtin grep
* as/maint-shortlog-cleanup (Tue Dec 30 22:01:44 2008 +0100) 1 commit
+ builtin-shortlog.c: use string_list_append(), and don't strdup
unnecessarily
* jc/maint-ls-tree (Wed Dec 31 19:00:50 2008 +0900) 2 commits
+ Document git-ls-tree --full-tree
+ ls-tree: add --full-tree option
* js/bundle-tags (Fri Jan 2 19:08:46 2009 +0100) 1 commit
+ bundle: allow rev-list options to exclude annotated tags
* js/add-not-submodule (Fri Jan 2 19:08:40 2009 +0100) 1 commit
+ git add: do not add files from a submodule
* pb/maint-git-pm-false-dir (Mon Dec 29 01:25:00 2008 +0100) 1 commit
+ Git.pm: correctly handle directory name that evaluates to "false"
* pj/maint-ldflags (Sun Jan 4 21:27:41 2009 -0500) 1 commit
+ configure clobbers LDFLAGS
* fe/cvsserver (Fri Jan 2 16:40:14 2009 +0100) 2 commits
+ cvsserver: change generation of CVS author names
+ cvsserver: add option to configure commit message
* js/maint-bisect-gitk (Fri Jan 2 19:08:00 2009 +0100) 1 commit
+ bisect view: call gitk if Cygwin's SESSIONNAME variable is set
* np/no-loosen-prune-expire-now (Tue Dec 30 14:45:11 2008 -0500) 1 commit
+ objects to be pruned immediately don't have to be loosened
* cb/maint-unpack-trees-absense (Thu Jan 1 21:54:33 2009 +0100) 3 commits
+ unpack-trees: remove redundant path search in verify_absent
+ unpack-trees: fix path search bug in verify_absent
+ unpack-trees: handle failure in verify_absent
* mc/cd-p-pwd (Tue Dec 30 07:10:24 2008 -0800) 1 commit
+ git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on
OS X
* mh/cherry-default (Thu Jan 1 22:56:29 2009 +0100) 2 commits
+ Documentation: clarify which parameters are optional to git-cherry
+ git-cherry: make <upstream> parameter optional
Some of the above will still need to be downmerged to respective
maintenance branches after they are widely used on 'master'.
----------------------------------------------------------------
[Will merge to "master" soon]
* mh/maint-commit-color-status (Thu Jan 8 19:53:05 2009 +0100) 2 commits
+ git-status -v: color diff output when color.ui is set
+ git-commit: color status output when color.ui is set
* rs/maint-shortlog-foldline (Tue Jan 6 21:41:06 2009 +0100) 1 commit
+ shortlog: handle multi-line subjects like log --pretty=oneline et.
al. do
* rs/fgrep (Sat Jan 10 00:18:34 2009 +0100) 2 commits
+ grep: don't call regexec() for fixed strings
+ grep -w: forward to next possible position after rejected match
* as/autocorrect-alias (Sun Jan 4 18:16:01 2009 +0100) 1 commit
+ git.c: make autocorrected aliases work
* tr/maint-no-index-fixes (Wed Jan 7 12:15:30 2009 +0100) 3 commits
+ diff --no-index -q: fix endless loop
+ diff --no-index: test for pager after option parsing
+ diff: accept -- when using --no-index
* jc/maint-format-patch (Sat Jan 10 12:41:33 2009 -0800) 1 commit
+ format-patch: show patch text for the root commit
* ap/clone-into-empty (Sun Jan 11 15:19:12 2009 +0300) 2 commits
+ Allow cloning to an existing empty directory
+ add is_dot_or_dotdot inline function
* gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
+ gitweb: link to patch(es) view in commit(diff) and (short)log view
+ gitweb: add patches view
+ gitweb: change call pattern for git_commitdiff
+ gitweb: add patch view
----------------------------------------------------------------
[On Hold]
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
2009-01-14 11:32 What's cooking in git.git (Jan 2009, #03; Wed, 14) Junio C Hamano
@ 2009-01-15 19:49 ` Kirill Smelkov
2009-01-15 20:39 ` Junio C Hamano
0 siblings, 1 reply; 11+ messages in thread
From: Kirill Smelkov @ 2009-01-15 19:49 UTC (permalink / raw
To: Junio C Hamano; +Cc: git
On Wed, Jan 14, 2009 at 03:32:32AM -0800, Junio C Hamano wrote:
[...]
> [Actively cooking]
>
> * gb/gitweb-opml (Fri Jan 2 13:49:30 2009 +0100) 2 commits
> + gitweb: suggest name for OPML view
> + gitweb: don't use pathinfo for global actions
>
> * ks/maint-mailinfo-folded (Mon Jan 12 15:22:11 2009 -0800) 2 commits
> - mailinfo: 'From:' header should be unfold as well
> - mailinfo: correctly handle multiline 'Subject:' header
>
> The author seems to have more updates, but I couldn't extract them from
> the e-mail.
Sorry for the inconvenience, and please pull them all from
git://repo.or.cz/git/kirr.git for-junio
Kirill Smelkov (4):
mailinfo: 'From:' header should be unfold as well
mailinfo: more smarter removal of rfc822 comments from 'From'
mailinfo: correctly handle multiline 'Subject:' header
mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
Thanks,
Kirill
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
2009-01-15 19:49 ` Kirill Smelkov
@ 2009-01-15 20:39 ` Junio C Hamano
2009-01-16 8:08 ` Kirill Smelkov
0 siblings, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2009-01-15 20:39 UTC (permalink / raw
To: Kirill Smelkov; +Cc: git
Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> Sorry for the inconvenience, and please pull them all from
>
> git://repo.or.cz/git/kirr.git for-junio
>
> Kirill Smelkov (4):
> mailinfo: 'From:' header should be unfold as well
> mailinfo: more smarter removal of rfc822 comments from 'From'
> mailinfo: correctly handle multiline 'Subject:' header
> mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
Sorry, but I cannot _pull_ this one; not because these four patches are
bad (I haven't looked at them).
They include all the other totally unrelated stuff that happend on the
master branch since the topic ks/maint-mailinfo-folded forked. I've been
hoping upon completion of this topic we can merge it down to maint to
propagate the fix back to v1.6.1.X series.
With this alias:
$ git config alias.lg log --pretty=oneline --abbrev-commit --boundary --left-right
Here are what I have queued so far (and they are in next):
$ git lg master..ks/maint-mailinfo-folded
>ddfb369... mailinfo: 'From:' header should be unfold as well
>353aaf2... mailinfo: correctly handle multiline 'Subject:' header
-141201d... Merge branch 'maint-1.5.6' into maint-1.6.0
$ git lg maint..ks/maint-mailinfo-folded
>ddfb369... mailinfo: 'From:' header should be unfold as well
>353aaf2... mailinfo: correctly handle multiline 'Subject:' header
-141201d... Merge branch 'maint-1.5.6' into maint-1.6.0
141201d is only three commits ahead of v1.6.0.6 and
$ git lg v1.6.0.6..141201d
will show that we _could_ even issue v1.6.0.7 with the fixes in this topic
if we cared about this bug deeply enough. If I pull the above to the
topic, we'll lose the ability to propagate these fixes to the maintenance
serires.
So please either say "Yes, you are welcome to cherry-pick -- fetching and
cherry-picking would be easier than e-mail for this kind of patch", or
"Ok, I'll rebase my series on top of ddfb369".
Well, I just noticed that some of your commits already conflict with the
two patches that I already have, so I guess we would need at least one
rebase anyway, so this time around, I'd really prefer you not to say "you
are welcome to cherry-pick" ;-)
Thanks.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
2009-01-15 20:39 ` Junio C Hamano
@ 2009-01-16 8:08 ` Kirill Smelkov
2009-01-16 8:21 ` Junio C Hamano
0 siblings, 1 reply; 11+ messages in thread
From: Kirill Smelkov @ 2009-01-16 8:08 UTC (permalink / raw
To: Junio C Hamano; +Cc: git
On Thu, Jan 15, 2009 at 12:39:06PM -0800, Junio C Hamano wrote:
> Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
>
> > Sorry for the inconvenience, and please pull them all from
> >
> > git://repo.or.cz/git/kirr.git for-junio
> >
> > Kirill Smelkov (4):
> > mailinfo: 'From:' header should be unfold as well
> > mailinfo: more smarter removal of rfc822 comments from 'From'
> > mailinfo: correctly handle multiline 'Subject:' header
> > mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
>
> Sorry, but I cannot _pull_ this one; not because these four patches are
> bad (I haven't looked at them).
>
> They include all the other totally unrelated stuff that happend on the
> master branch since the topic ks/maint-mailinfo-folded forked. I've been
> hoping upon completion of this topic we can merge it down to maint to
> propagate the fix back to v1.6.1.X series.
>
> With this alias:
>
> $ git config alias.lg log --pretty=oneline --abbrev-commit --boundary --left-right
>
> Here are what I have queued so far (and they are in next):
>
> $ git lg master..ks/maint-mailinfo-folded
> >ddfb369... mailinfo: 'From:' header should be unfold as well
> >353aaf2... mailinfo: correctly handle multiline 'Subject:' header
> -141201d... Merge branch 'maint-1.5.6' into maint-1.6.0
>
> $ git lg maint..ks/maint-mailinfo-folded
> >ddfb369... mailinfo: 'From:' header should be unfold as well
> >353aaf2... mailinfo: correctly handle multiline 'Subject:' header
> -141201d... Merge branch 'maint-1.5.6' into maint-1.6.0
>
> 141201d is only three commits ahead of v1.6.0.6 and
>
> $ git lg v1.6.0.6..141201d
>
> will show that we _could_ even issue v1.6.0.7 with the fixes in this topic
> if we cared about this bug deeply enough. If I pull the above to the
> topic, we'll lose the ability to propagate these fixes to the maintenance
> serires.
>
> So please either say "Yes, you are welcome to cherry-pick -- fetching and
> cherry-picking would be easier than e-mail for this kind of patch", or
> "Ok, I'll rebase my series on top of ddfb369".
>
> Well, I just noticed that some of your commits already conflict with the
> two patches that I already have, so I guess we would need at least one
> rebase anyway, so this time around, I'd really prefer you not to say "you
> are welcome to cherry-pick" ;-)
Sure, I've rebased my series on top of ddfb369 :)
git://repo.or.cz/git/kirr.git for-junio-maint
Kirill Smelkov (3):
mailinfo: more smarter removal of rfc822 comments from 'From'
mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
mailinfo: tests for RFC2047 examples
Thanks,
Kirill
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
2009-01-16 8:08 ` Kirill Smelkov
@ 2009-01-16 8:21 ` Junio C Hamano
2009-01-16 11:54 ` Johannes Schindelin
0 siblings, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2009-01-16 8:21 UTC (permalink / raw
To: Kirill Smelkov; +Cc: git
Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> On Thu, Jan 15, 2009 at 12:39:06PM -0800, Junio C Hamano wrote:
> ...
>> So please either say "Yes, you are welcome to cherry-pick -- fetching and
>> cherry-picking would be easier than e-mail for this kind of patch", or
>> "Ok, I'll rebase my series on top of ddfb369".
>>
>> Well, I just noticed that some of your commits already conflict with the
>> two patches that I already have, so I guess we would need at least one
>> rebase anyway, so this time around, I'd really prefer you not to say "you
>> are welcome to cherry-pick" ;-)
>
> Sure, I've rebased my series on top of ddfb369 :)
>
> git://repo.or.cz/git/kirr.git for-junio-maint
>
>
> Kirill Smelkov (3):
> mailinfo: more smarter removal of rfc822 comments from 'From'
> mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
> mailinfo: tests for RFC2047 examples
Thanks.
I thought there is somebody on this list who insists his name is of form:
From: A U Thor (MonikeR) <a.u@thor.xz>
and vaguely recall the current code was tweaked to keep that extra moniker
in his (or her?) name. It is too late at night for me to double check but
I suspect the first one in the series may break things for that kind of
names.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
2009-01-16 8:21 ` Junio C Hamano
@ 2009-01-16 11:54 ` Johannes Schindelin
2009-01-18 14:54 ` Kirill Smelkov
0 siblings, 1 reply; 11+ messages in thread
From: Johannes Schindelin @ 2009-01-16 11:54 UTC (permalink / raw
To: Junio C Hamano; +Cc: Kirill Smelkov, git
Hi,
On Fri, 16 Jan 2009, Junio C Hamano wrote:
> I thought there is somebody on this list who insists his name is of form:
>
> From: A U Thor (MonikeR) <a.u@thor.xz>
It is Philippe Bruhat (BooK), who sometimes forgets the closing
parenthesis, and who is listed in .mailmap without the moniker.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
2009-01-16 11:54 ` Johannes Schindelin
@ 2009-01-18 14:54 ` Kirill Smelkov
2009-01-18 18:50 ` John (zzz) Doe <john.doe@xz> (Comment) Junio C Hamano
0 siblings, 1 reply; 11+ messages in thread
From: Kirill Smelkov @ 2009-01-18 14:54 UTC (permalink / raw
To: Johannes Schindelin; +Cc: Junio C Hamano, git
On Fri, Jan 16, 2009 at 12:54:28PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 16 Jan 2009, Junio C Hamano wrote:
>
> > I thought there is somebody on this list who insists his name is of form:
> >
> > From: A U Thor (MonikeR) <a.u@thor.xz>
>
> It is Philippe Bruhat (BooK), who sometimes forgets the closing
> parenthesis, and who is listed in .mailmap without the moniker.
So now I don't understand what to do.
>From one hand RFC822 says '(...)' is a comment, and from the other hand,
we have a use case where one guy wants this to stay.
For the record, here is the questionable patch. Any suggestion?
Thanks,
Kirill
commit 49bebfbe18dac296e5e246884bd98c1f90be9676
Author: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Date: Tue Jan 13 01:21:04 2009 +0300
mailinfo: more smarter removal of rfc822 comments from 'From'
As described in RFC822 (3.4.3 COMMENTS, and A.1.4.), comments, as e.g.
John (zzz) Doe <john.doe@xz> (Comment)
should "NOT [be] included in the destination mailbox"
We need this functionality to pass all RFC2047 based tests in the next commit.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index dacc8ac..958c905 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -29,6 +29,9 @@ static struct strbuf **p_hdr_data, **s_hdr_data;
#define MAX_HDR_PARSED 10
#define MAX_BOUNDARIES 5
+static void cleanup_space(struct strbuf *sb);
+
+
static void get_sane_name(struct strbuf *out, struct strbuf *name, struct strbuf *email)
{
struct strbuf *src = name;
@@ -120,6 +123,33 @@ static void handle_from(const struct strbuf *from)
strbuf_setlen(&f, f.len - 1);
}
+ /* This still could not be finished for emails like
+ *
+ * "John (zzz) Doe <john.doe@xz> (Comment)"
+ *
+ * The email part had already been removed, so let's kill comments as
+ * well -- RFC822 says comments should not be present in destination
+ * mailbox (3.4.3. Comments and A.1.4.)
+ */
+ while (1) {
+ char *ta;
+
+ at = strchr(f.buf, '(');
+ if (!at)
+ break;
+ ta = strchr(at, ')');
+ if (!ta)
+ break;
+
+ strbuf_remove(&f, at - f.buf, ta-at + (*ta ? 1 : 0));
+ }
+
+ /* and let's finally cleanup spaces that were around (possibly
+ * internal) comments
+ */
+ cleanup_space(&f);
+ strbuf_trim(&f);
+
get_sane_name(&name, &f, &email);
strbuf_release(&f);
}
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 38725f3..4f80b82 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -2,10 +2,10 @@
From nobody Mon Sep 17 00:00:00 2001
-From: A
+From: A (zzz)
U
Thor
- <a.u.thor@example.com>
+ <a.u.thor@example.com> (Comment)
Date: Fri, 9 Jun 2006 00:44:16 -0700
Subject: [PATCH] a commit.
^ permalink raw reply related [flat|nested] 11+ messages in thread
* John (zzz) Doe <john.doe@xz> (Comment)
2009-01-18 14:54 ` Kirill Smelkov
@ 2009-01-18 18:50 ` Junio C Hamano
2009-01-20 19:14 ` Kirill Smelkov
0 siblings, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2009-01-18 18:50 UTC (permalink / raw
To: Kirill Smelkov; +Cc: Johannes Schindelin, git
Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> On Fri, Jan 16, 2009 at 12:54:28PM +0100, Johannes Schindelin wrote:
> ...
>> > From: A U Thor (MonikeR) <a.u@thor.xz>
>>
>> It is Philippe Bruhat (BooK), who sometimes forgets the closing
>> parenthesis, and who is listed in .mailmap without the moniker.
It was not "forgets", but is an artifact that older mailinfo removed
parenthesis incorrectly (see below).
> So now I don't understand what to do.
>
> From one hand RFC822 says '(...)' is a comment, and from the other hand,
> we have a use case where one guy wants this to stay.
> ...
> commit 49bebfbe18dac296e5e246884bd98c1f90be9676
> Author: Kirill Smelkov <kirr@landau.phys.spbu.ru>
> Date: Tue Jan 13 01:21:04 2009 +0300
>
> mailinfo: more smarter removal of rfc822 comments from 'From'
>
> As described in RFC822 (3.4.3 COMMENTS, and A.1.4.), comments, as e.g.
>
> John (zzz) Doe <john.doe@xz> (Comment)
>
> should "NOT [be] included in the destination mailbox"
The above quote from the RFC is irrelevant. Note that it is only about
how you extract the e-mail address, discarding everything else.
What mailinfo wants to do is to separate the human-readable name and the
e-mail address, and we want to use _both_ results from it.
We separate a few example From: lines like this:
Kirill Smelkov <kirr@smelkov.xz>
==> AUTHOR_EMAIL="kirr@smelkov.xz" AUTHOR_NAME="Kirill Smelkov"
kirr@smelkov.xz (Kirill Smelkov)
==> AUTHOR_EMAIL="kirr@smelkov.xz" AUTHOR_NAME="Kirill Smelkov"
Traditionally, the way people spelled their name on From: line has been
either one of the above form. Typically comment form (i.e. the second
one) adds the name at the end, while "Name <addr>" form has the name at
the front. But I do not think RFC requires that, primarily because it is
all about discarding non-address part to find the e-mail address aka
"destination mailbox". It does not specify how humans should interpret
the human readable name and the comment.
Now, why is the name not AUTHOR_NAME="(Kirill Smelkov)" in the latter
form?
It is just common sense transformation. Otherwise it looks simply ugly,
and it is obvious that the parentheses is not part of the name of the
person who used "kirr@smelkov.xz (Kirill Smelkov)" on his From: line.
So we can separate "John (zzz) Doe <john.doe@xz> (Comment)" into:
AUTHOR_EMAIL=john.doe@xz
AUTHOR_NAME="John (zzz) Doe (Comment)"
and leave it like so, I think.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: John (zzz) Doe <john.doe@xz> (Comment)
2009-01-18 18:50 ` John (zzz) Doe <john.doe@xz> (Comment) Junio C Hamano
@ 2009-01-20 19:14 ` Kirill Smelkov
2009-01-21 3:12 ` Junio C Hamano
0 siblings, 1 reply; 11+ messages in thread
From: Kirill Smelkov @ 2009-01-20 19:14 UTC (permalink / raw
To: Junio C Hamano; +Cc: Johannes Schindelin, git
On Sun, Jan 18, 2009 at 10:50:12AM -0800, Junio C Hamano wrote:
> So we can separate "John (zzz) Doe <john.doe@xz> (Comment)" into:
>
> AUTHOR_EMAIL=john.doe@xz
> AUTHOR_NAME="John (zzz) Doe (Comment)"
>
> and leave it like so, I think.
Ok, here you are:
Subject: [PATCH 1/3] mailinfo: cleanup extra spaces for complex 'From'
As described in RFC822 (3.4.3 COMMENTS, and A.1.4.), comments, as e.g.
John (zzz) Doe <john.doe@xz> (Comment)
should "NOT [be] included in the destination mailbox"
On the other hand, quoting Junio:
> The above quote from the RFC is irrelevant. Note that it is only about
> how you extract the e-mail address, discarding everything else.
>
> What mailinfo wants to do is to separate the human-readable name and the
> e-mail address, and we want to use _both_ results from it.
>
> We separate a few example From: lines like this:
>
> Kirill Smelkov <kirr@smelkov.xz>
> ==> AUTHOR_EMAIL="kirr@smelkov.xz" AUTHOR_NAME="Kirill Smelkov"
>
> kirr@smelkov.xz (Kirill Smelkov)
> ==> AUTHOR_EMAIL="kirr@smelkov.xz" AUTHOR_NAME="Kirill Smelkov"
>
> Traditionally, the way people spelled their name on From: line has been
> either one of the above form. Typically comment form (i.e. the second
> one) adds the name at the end, while "Name <addr>" form has the name at
> the front. But I do not think RFC requires that, primarily because it is
> all about discarding non-address part to find the e-mail address aka
> "destination mailbox". It does not specify how humans should interpret
> the human readable name and the comment.
>
> Now, why is the name not AUTHOR_NAME="(Kirill Smelkov)" in the latter
> form?
>
> It is just common sense transformation. Otherwise it looks simply ugly,
> and it is obvious that the parentheses is not part of the name of the
> person who used "kirr@smelkov.xz (Kirill Smelkov)" on his From: line.
>
> So we can separate "John (zzz) Doe <john.doe@xz> (Comment)" into:
>
> AUTHOR_EMAIL=john.doe@xz
> AUTHOR_NAME="John (zzz) Doe (Comment)"
>
> and leave it like so, I think.
So let's just correctly remove extra spaces which could be left inside
name.
We need this functionality to pass all RFC2047 based tests in the next commit.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
builtin-mailinfo.c | 21 +++++++++++++++++----
t/t5100/info0001 | 2 +-
t/t5100/sample.mbox | 4 ++--
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index dacc8ac..8030823 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -29,6 +29,9 @@ static struct strbuf **p_hdr_data, **s_hdr_data;
#define MAX_HDR_PARSED 10
#define MAX_BOUNDARIES 5
+static void cleanup_space(struct strbuf *sb);
+
+
static void get_sane_name(struct strbuf *out, struct strbuf *name, struct strbuf *email)
{
struct strbuf *src = name;
@@ -109,10 +112,14 @@ static void handle_from(const struct strbuf *from)
strbuf_add(&email, at, el);
strbuf_remove(&f, at - f.buf, el + (at[el] ? 1 : 0));
- /* The remainder is name. It could be "John Doe <john.doe@xz>"
- * or "john.doe@xz (John Doe)", but we have removed the
- * email part, so trim from both ends, possibly removing
- * the () pair at the end.
+ /* The remainder is name. It could be
+ *
+ * - "John Doe <john.doe@xz>" (a), or
+ * - "john.doe@xz (John Doe)" (b), or
+ * - "John (zzz) Doe <john.doe@xz> (Comment)" (c)
+ *
+ * but we have removed the email part, so trim from both ends, possibly
+ * removing the () pair at the end for case 'b'.
*/
strbuf_trim(&f);
if (f.buf[0] == '(' && f.len && f.buf[f.len - 1] == ')') {
@@ -120,6 +127,12 @@ static void handle_from(const struct strbuf *from)
strbuf_setlen(&f, f.len - 1);
}
+ /* Otherwise we want comments to stay. It's just time to cleanup extra
+ * spaces
+ */
+ cleanup_space(&f);
+ strbuf_trim(&f);
+
get_sane_name(&name, &f, &email);
strbuf_release(&f);
}
diff --git a/t/t5100/info0001 b/t/t5100/info0001
index 8c05277..f951538 100644
--- a/t/t5100/info0001
+++ b/t/t5100/info0001
@@ -1,4 +1,4 @@
-Author: A U Thor
+Author: A (zzz) U Thor (Comment)
Email: a.u.thor@example.com
Subject: a commit.
Date: Fri, 9 Jun 2006 00:44:16 -0700
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 38725f3..4f80b82 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -2,10 +2,10 @@
From nobody Mon Sep 17 00:00:00 2001
-From: A
+From: A (zzz)
U
Thor
- <a.u.thor@example.com>
+ <a.u.thor@example.com> (Comment)
Date: Fri, 9 Jun 2006 00:44:16 -0700
Subject: [PATCH] a commit.
--
1.6.1.79.g92b9.dirty
Is it ok?
And by the way, please pull the whole updated series from
git://repo.or.cz/git/kirr.git for-junio-maint
Kirill Smelkov (3):
mailinfo: cleanup extra spaces for complex 'From'
mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
mailinfo: tests for RFC2047 examples
Thanks,
Kirill
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: John (zzz) Doe <john.doe@xz> (Comment)
2009-01-20 19:14 ` Kirill Smelkov
@ 2009-01-21 3:12 ` Junio C Hamano
2009-01-21 20:30 ` Kirill Smelkov
0 siblings, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2009-01-21 3:12 UTC (permalink / raw
To: Kirill Smelkov; +Cc: Johannes Schindelin, git
Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> On Sun, Jan 18, 2009 at 10:50:12AM -0800, Junio C Hamano wrote:
>> So we can separate "John (zzz) Doe <john.doe@xz> (Comment)" into:
>>
>> AUTHOR_EMAIL=john.doe@xz
>> AUTHOR_NAME="John (zzz) Doe (Comment)"
>>
>> and leave it like so, I think.
>
> Ok, here you are:
>
> Subject: [PATCH 1/3] mailinfo: cleanup extra spaces for complex 'From'
>
> As described in RFC822 (3.4.3 COMMENTS, and A.1.4.), comments, as e.g.
>
> John (zzz) Doe <john.doe@xz> (Comment)
>
> should "NOT [be] included in the destination mailbox"
>
> On the other hand, quoting Junio:
>
>> The above quote from the RFC is irrelevant. Note that it is only about
>> how you extract the e-mail address, discarding everything else.
>>
>> What mailinfo wants to do is to separate the human-readable name and the
>> e-mail address, and we want to use _both_ results from it.
>>
>> We separate a few example From: lines like this:
>>
>> Kirill Smelkov <kirr@smelkov.xz>
>> ==> AUTHOR_EMAIL="kirr@smelkov.xz" AUTHOR_NAME="Kirill Smelkov"
>>
>> kirr@smelkov.xz (Kirill Smelkov)
>> ==> AUTHOR_EMAIL="kirr@smelkov.xz" AUTHOR_NAME="Kirill Smelkov"
>>
>> Traditionally, the way people spelled their name on From: line has been
>> either one of the above form. Typically comment form (i.e. the second
>> one) adds the name at the end, while "Name <addr>" form has the name at
>> the front. But I do not think RFC requires that, primarily because it is
>> all about discarding non-address part to find the e-mail address aka
>> "destination mailbox". It does not specify how humans should interpret
>> the human readable name and the comment.
>>
>> Now, why is the name not AUTHOR_NAME="(Kirill Smelkov)" in the latter
>> form?
>>
>> It is just common sense transformation. Otherwise it looks simply ugly,
>> and it is obvious that the parentheses is not part of the name of the
>> person who used "kirr@smelkov.xz (Kirill Smelkov)" on his From: line.
>>
>> So we can separate "John (zzz) Doe <john.doe@xz> (Comment)" into:
>>
>> AUTHOR_EMAIL=john.doe@xz
>> AUTHOR_NAME="John (zzz) Doe (Comment)"
>>
>> and leave it like so, I think.
>
> So let's just correctly remove extra spaces which could be left inside
> name.
>
> We need this functionality to pass all RFC2047 based tests in the next commit.
>
> Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
> ---
> ...
> Is it ok?
I think the patch text looks good, but what you have as the proposed
commit log message does not look anything like log message we usually use.
- If you agree with my comment that "should NOT be included" from the RFC
you quoted is irrelevant, then I do not think you would even want to
have anything before "On the other hand,...".
- If you disagree, then why are you bending the patch text to match what
I say? ;-)
Also I am not sure "passing RFC2047 based tests" is a valid purpose nor
justification for adding this patch (because you could argue that the
tests and the results the tests expect are faulty).
The way we (and your patches) do thinks is to have the desired outcome
designed first, and then have tests to make sure that the implementation
matches the desired outcome.
Given that, what I would probably suggest would be...
-- 8< -- cut from here -- 8< --
mailinfo: handle comment fields in From: line sanely
Most commonly, people have their human readable name and their e-mail
address on their From: line in one of two formats:
Kirill Smelkov <kirr@smelkov.xz>
kirr@smelkov.xz (Kirill Smelkov)
In addition, you can have "Comments" in parentheses at random places, like
this:
John (zzz) Doe <john.doe@xz> (Comment)
RFC822 defines rules to extract the "destination mailbox" out of such
input (and we correctly extract "kirr@smelkov.xz" and "john.doe@xz" from
these examples). It however does not specify how to pick up the human
readable name from the remainder, and the existing code randomly dropped
pieces of information in <<<this and that way --- explain the breakage you
wanted to fix with your patch, perhaps "and left a newline in the result"
may be one of the breakages>>>.
This patch changes the rule so that <<<explain what it does here. I think
what the code does is (1) remove the e-mail (and angle brackets around
it), (2) sanitize LF into a single SP to keep the result a single line,
and (3) as a special case, if the result is enclosed by () pair, remove
them---this rule is to format the second common case listed above
sanely>>>.
A subsequent patch using From: lines taken from the example section of
RFC2047 will test this feature.
-- >8 --
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: John (zzz) Doe <john.doe@xz> (Comment)
2009-01-21 3:12 ` Junio C Hamano
@ 2009-01-21 20:30 ` Kirill Smelkov
0 siblings, 0 replies; 11+ messages in thread
From: Kirill Smelkov @ 2009-01-21 20:30 UTC (permalink / raw
To: Junio C Hamano; +Cc: Johannes Schindelin, git
On Tue, Jan 20, 2009 at 07:12:54PM -0800, Junio C Hamano wrote:
> Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> > Is it ok?
>
> I think the patch text looks good, but what you have as the proposed
> commit log message does not look anything like log message we usually use.
>
> - If you agree with my comment that "should NOT be included" from the RFC
> you quoted is irrelevant, then I do not think you would even want to
> have anything before "On the other hand,...".
>
> - If you disagree, then why are you bending the patch text to match what
> I say? ;-)
I agree, really :)
It's only me usually tired in the end of the day, like today too.
I'll try to have a rest and will reply with updated patch.
Thanks,
Kirill
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-01-21 20:31 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-14 11:32 What's cooking in git.git (Jan 2009, #03; Wed, 14) Junio C Hamano
2009-01-15 19:49 ` Kirill Smelkov
2009-01-15 20:39 ` Junio C Hamano
2009-01-16 8:08 ` Kirill Smelkov
2009-01-16 8:21 ` Junio C Hamano
2009-01-16 11:54 ` Johannes Schindelin
2009-01-18 14:54 ` Kirill Smelkov
2009-01-18 18:50 ` John (zzz) Doe <john.doe@xz> (Comment) Junio C Hamano
2009-01-20 19:14 ` Kirill Smelkov
2009-01-21 3:12 ` Junio C Hamano
2009-01-21 20:30 ` Kirill Smelkov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.