* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Jens Lehmann @ 2009-10-07 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vocok21pw.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>>> But I really, really, really want to avoid a fork() in the common case. I
>>> do have some users on Windows, and I do have a few submodules in that
>>> project. Having too many fork() calls there would just give Git a bad
>>> reputation. And it has enough of that, it does not need more.
>> Me too thinks performance matters here. We do have a repo at my dayjob
>> with more than a handful of submodules and its main target platform is
>> windows ... so having that perform nicely is a win for us.
>
> Numbers?
Here they are:
First i did them with the repo at hand, current msysgit master with
Dscho's git-repo checked out:
without fork : real 0m0.672s
with fork : real 0m0.781s
So here it's a about 16% slower when using fork() (and both are
generating about 7270 shortlog entries).
But i thought this to be a rather unusual situation, having only one
submodule being changed by 7270 commits ...
So i took a live repo from my dayjob containing 8 submodules. In each
submodule i did a "git checkout HEAD^" to simulate one change. And
then i got:
without fork : real 0m0.203s
with fork : real 0m0.453s
This is a degradation of more than 120% because of the fork()s. And
just for fun i ran the scripted submodule summary too:
scripted : real 0m3.437s
So the forked version outperforms the scripted version by a factor of
7, while the speedup from Dscho's original proposal is almost 17fold.
(If i did my computations right, the extra costs for each changed
submodule are a bit more than 30ms when fork()ing. Dscho's version
doesn't seem to suffer from changed submodules at all, i measured
0.203s for both versions before i did the submodule init and update).
(Best of three, "time git diff --submodule-summary". My system is an
Athlon64x2 4600+ with WindowsXP)
Jens
^ permalink raw reply
* Re: [PATCH 2/3] completion: update am, commit, and log
From: Junio C Hamano @ 2009-10-07 19:45 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <1254905331-29516-2-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> git am learned --scissors, git commit learned --dry-run and git log
> learned --decorate=long|short recently.
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
No objection from me, but I am not a completion expert ;-)
^ permalink raw reply
* Re: [PATCH 3/3] completion: add dirstat and friends to diff options
From: Junio C Hamano @ 2009-10-07 19:45 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <1254905331-29516-3-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
No objection from me, but I am not a completion expert ;-)
^ permalink raw reply
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Junio C Hamano @ 2009-10-07 20:00 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Johannes Schindelin, git
In-Reply-To: <4ACCECE6.1030508@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> So i took a live repo from my dayjob containing 8 submodules. In each
> submodule i did a "git checkout HEAD^" to simulate one change.
It appears that your "simulation" is to have changes in all submodules and
nowhere else in the tree. I have to wonder how common would that be. If
I have been working in the subprojects without changing the superproject
at all, I would likely to be in one of the subproject directories and my
"git diff" would not even have to trigger this codepath. If we have on
the other hand changes in the superproject, showing them would cost us
equally in both approaches.
> then i got:
>
> without fork : real 0m0.203s
> with fork : real 0m0.453s
>
> This is a degradation of more than 120% because of the fork()s. And
> just for fun i ran the scripted submodule summary too:
>
> scripted : real 0m3.437s
>
> So the forked version outperforms the scripted version by a factor of
> 7, while the speedup from Dscho's original proposal is almost 17fold.
Thanks. I was worried if the forking to ensure correctness may sactifice
performance so much to be unusable, but it does not seem to be the case,
given the above comparision.
I didn't look at the code but presumably it uses the run_command()
interface and cleanly written?
^ permalink raw reply
* Re: [PATCH/RFC] New date format: local_original
From: Junio C Hamano @ 2009-10-07 20:01 UTC (permalink / raw)
To: Jeff King; +Cc: Tuomas Suutari, git
In-Reply-To: <20091007125427.GA20067@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> If the former, then should the options be orthogonal? That is, should it
> be a new format combining the two, or should it be an option to show, in
> your preferred format, the time in both local and original time zones?
> E.g., something like:
>
> $ git log --date=iso --local-dates-too
> commit bf01a69ed40e1afcf56aff143f7523da2ce263ed
> Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: 2009-10-04 00:41:55 +0200
> Local: 2009-10-03 17:41:55 -0500
>
> And then you can use it with "normal" dates, iso dates, rfc2822 dates,
> etc.
Thanks for comments.
I think "--date=iso --local-dates-too" is still not orthogonal enough, let
alone "local_original" which invites "Why is this combination supported
and not this, that, and 47 others?" questions.
I however do not think it is so bad an idea to allow something like:
git log --date='custom:%Y-%m-%d ...'
git log --date=custom ;# looks at "date.custom" config
You (not Peff, but figuratively whoever wants to implement it) can add a
mechanism to specify in which timezone (original or local) you would want
the timestring to be given, and make what Tuomas's RFC patch does a mere
special case. For example, we could reuse 'date "+format"' string with
our own extension %{magic}, with two magic tokens initially defined:
%{local} interpret timestamp in local zone from now on
%{original} interpret timestamp in the original zone from now on
With such a mechanism Tuomas can define:
[date]
custom=%{local}%a %Y-%m-%d %H:%M:%S %{original}(%a %H:%M:%S %z)
and ask "git log --date=custom" to get what his patch does.
^ permalink raw reply
* Re: gitweb calls the project ".git"
From: Daniele Segato @ 2009-10-07 20:01 UTC (permalink / raw)
To: Lars Rasmusson; +Cc: git
In-Reply-To: <E66B0797-4EF0-49FC-AA01-8FD4C884A7E9@sics.se>
Il giorno mer, 07/10/2009 alle 18.31 +0200, Lars Rasmusson ha scritto:
> Hi, I am serving a repository with "git instaweb".
>
> In the web browser, the name in the Project column is only ".git", and
> not the "myrepo.git"
> which I would like to have, and as it is on http://repo.or.cz/ (which
> is a site that also uses gitweb).
>
> How do I configure it to serve the project directory (or even better,
> all the repos in a directory), and name them appropriately?
>
> (Is it possible to do with instaweb, or can it only be done with a
> more heavy approach like using apache?)
as for I know by default you should create a simbolic link to your .git
directory in /var/cache/git/
the name of the project depends of the name of the symbolic link
example: /var/cache/git/yourproject.git --> /your/project/path/.git/
Bye,
Daniele
^ permalink raw reply
* Re: Code reuse
From: Philip Herron @ 2009-10-07 20:12 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <2e24e5b90910070530p757b3651ne0f7e4a6e8bc8825@mail.gmail.com>
Thanks for that i am no legalese speaker so yeah ;). Its only really
the alloc_nr but its renamed is nearly the same the other really isnt
the same only just 2 statements with different identifiers remain.
Thanks anyways git-core is nice :)
--Phil
2009/10/7 Sitaram Chamarty <sitaramc@gmail.com>:
> On Wed, Oct 7, 2009 at 12:48 AM, Philip Herron
> <herron.philip@googlemail.com> wrote:
>
>> I am not sure if this is the right place to ask this question, but
>> I've been working on a personal project a programming language
>> interpreter for some time now, but i took 2 code snippets from
>> git-core namely:
>
> [snip]
>
>> I've changed it a good bit (probably doesn't resemble much of what it
>> was) to fit in with the way my stuff works but is there anything i
>> need to like put in my source code to say hey this is based of
>> git-core, so far is just a comment to say 'based of git-core hash.c'.
>> Its an open source (GPL) program but i haven't released or made much
>> noise about it yet because i want to work on it more myself.
>
> In general, the GPL's main requirement is that whoever gets the binary
> should also get the code (I'm over simplifying but that's basically
> it). It actually doesn't say much about giving credit, except (from
> <HEAD:COPYING>):
>
> "If the software is modified by someone else and passed on, we want
> its recipients to know that what they have is not the original, so
> that any problems introduced by others will not reflect on the
> original authors' reputations"
>
> and
>
> "a) You must cause the modified files to carry prominent notices
> stating that you changed the files and the date of any change."
>
> That's basically it...
>
> It would seem to me that, if you changed them significantly, and going
> by the above logic, you don't need to do *anything* regarding
> attribution.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Code reuse
From: Florian Weimer @ 2009-10-07 20:15 UTC (permalink / raw)
To: git
In-Reply-To: <2e24e5b90910070530p757b3651ne0f7e4a6e8bc8825@mail.gmail.com>
* Sitaram Chamarty:
> It would seem to me that, if you changed them significantly, and going
> by the above logic, you don't need to do *anything* regarding
> attribution.
Note that applicable laws may impose additional restrictions, like
crediting authors in the way they require.
My personal approach is to include the copyright header of the file
I'm quoting from, together with a comment which explains where the
code came from (project, version, path).
^ permalink raw reply
* Re: Alles wurde Git
From: Phil Lawrence @ 2009-10-07 21:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <alpine.DEB.1.00.0910041310520.4985@pacific.mpi-cbg.de>
On 10/04/2009 07:09 AM, Johannes Schindelin wrote:
>
> ...Steffen also described some of the issues with
> working on a large number of topic branches that need to be
> integrated/cleaned up/rebased: Git lacks good tools for working
> collaboratively with topic branches that need to be rebased frequently.
> He also showed a rather complicated script that is necessary to coordinate
> work between 3 different maintainers (at 3 different locations).
> ...
Steffen, any chance you would share that script with the list? It
sounds very interesting.
Phil Lawrence
^ permalink raw reply
* Re: Alles wurde Git
From: Johannes Schindelin @ 2009-10-07 22:15 UTC (permalink / raw)
To: Phil Lawrence; +Cc: git, msysgit
In-Reply-To: <4ACD076B.3000902@gmail.com>
Hi,
On Wed, 7 Oct 2009, Phil Lawrence wrote:
> On 10/04/2009 07:09 AM, Johannes Schindelin wrote:
> >
> > ...Steffen also described some of the issues with working on a large
> > number of topic branches that need to be integrated/cleaned
> > up/rebased: Git lacks good tools for working collaboratively with
> > topic branches that need to be rebased frequently. He also showed a
> > rather complicated script that is necessary to coordinate work between
> > 3 different maintainers (at 3 different locations). ...
>
> Steffen, any chance you would share that script with the list? It
> sounds very interesting.
I fear that the script is rather specific to the company's environment,
and I fear further that Steffen might not be allowed to share it due to IP
issues.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Johannes Schindelin @ 2009-10-07 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git
In-Reply-To: <7vd44zt1nf.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 7 Oct 2009, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
> > So i took a live repo from my dayjob containing 8 submodules. In each
> > submodule i did a "git checkout HEAD^" to simulate one change.
>
> It appears that your "simulation" is to have changes in all submodules
> and nowhere else in the tree. I have to wonder how common would that
> be. If I have been working in the subprojects without changing the
> superproject at all, I would likely to be in one of the subproject
> directories and my "git diff" would not even have to trigger this
> codepath. If we have on the other hand changes in the superproject,
> showing them would cost us equally in both approaches.
>
> > then i got:
> >
> > without fork : real 0m0.203s
> > with fork : real 0m0.453s
> >
> > This is a degradation of more than 120% because of the fork()s. And
> > just for fun i ran the scripted submodule summary too:
> >
> > scripted : real 0m3.437s
> >
> > So the forked version outperforms the scripted version by a factor of
> > 7, while the speedup from Dscho's original proposal is almost 17fold.
>
> Thanks. I was worried if the forking to ensure correctness may sactifice
> performance so much to be unusable, but it does not seem to be the case,
> given the above comparision.
>
> I didn't look at the code but presumably it uses the run_command()
> interface and cleanly written?
You seem to be rather unconvinced by rather convincing numbers.
Therefore, I will continue working on the --submodule-summary stuff in
4msysgit.git.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] completion: add dirstat and friends to diff options
From: Junio C Hamano @ 2009-10-07 23:07 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Stephen Boyd, Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <20091007205059.GA16235@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
> On Wed, Oct 07, 2009 at 01:48:51AM -0700, Stephen Boyd wrote:
>> + --dirstat --dirstat= --dirstat-by-file
>> + --dirstat-by-file= --cumulative
>
> I'm a bit puzzled by having both --dirstat and --dirstat=, and
> --dirstat-by-file and --dirstat-by-file=. How do we complete similar
> long options, where an argument and hence the = char is optional?
A similar example in "git init" completion (--shared vs --shared=) already
exists, no?
^ permalink raw reply
* Re: [PATCH/RFC] New date format: local_original
From: Jeff King @ 2009-10-07 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tuomas Suutari, git
In-Reply-To: <7vocojrn26.fsf@alter.siamese.dyndns.org>
On Wed, Oct 07, 2009 at 01:01:05PM -0700, Junio C Hamano wrote:
> I think "--date=iso --local-dates-too" is still not orthogonal enough, let
> alone "local_original" which invites "Why is this combination supported
> and not this, that, and 47 others?" questions.
>
> I however do not think it is so bad an idea to allow something like:
>
> git log --date='custom:%Y-%m-%d ...'
> git log --date=custom ;# looks at "date.custom" config
Thanks, that (and the %{local} bit) is a much better suggestion than
mine, I think.
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] completion: add dirstat and friends to diff options
From: Stephen Boyd @ 2009-10-08 0:11 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <20091007233442.GJ6055@neumann>
SZEDER Gábor wrote:
> But there are no git log --stat=, --color-words= and --decorate=, but
> only --stat, --color-words and --decorate, and there are git log
> --pretty= and --format=, but no --pretty and --format. I have not
> looked at other commands yet.
>
I guess this is because nobody has added these. Feel free to send a
follow up patch.
^ permalink raw reply
* Re: [PATCH] Documentation - pt-BR.
From: Miklos Vajna @ 2009-10-08 0:12 UTC (permalink / raw)
To: Thiago Farina; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <a4c8a6d00910060820se973fcci31c94c42937c7eb2@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 741 bytes --]
On Tue, Oct 06, 2009 at 12:20:00PM -0300, Thiago Farina <tfransosi@gmail.com> wrote:
> > $ ls -1 /etc/asciidoc/lang-*
> > /etc/asciidoc/lang-de.conf
> > /etc/asciidoc/lang-en.conf
> > /etc/asciidoc/lang-es.conf
> > /etc/asciidoc/lang-fr.conf
> > /etc/asciidoc/lang-hu.conf
> > /etc/asciidoc/lang-ru.conf
> In my system I only have installed lang-es.conf, how I could install the others?
This is with asciidoc 8.5.0, I guess you have a bit older version.
> Sure, I made the lang-pt-BR.conf, and I sent it to asciidoc@googlegroups.com.
Great, then sooner or later you could have those 'NAME' and 'SYNOPSIS'
strings localised. Till then, I would suggest having them in English -
git typically supports building with older asciidoc versions.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [BUG?] gitweb search fails with non-ascii characters
From: Stephen Boyd @ 2009-10-08 1:03 UTC (permalink / raw)
To: git
Easiest way to trigger this is by putting á in the commit search box and
then hitting enter. On git.kernel.org you get a 403 Forbidden. On
gitweb.samba.org it works. I know that git.kernel.org is non-standard,
but I can reproduce locally when I run instaweb (I think my system could
be mis-configured though).
Even odder, in all cases the letter in the search box becomes mangled on
the results page. Meaning searching again by hitting enter will not be
the same (and actually makes the search box text even worse).
^ permalink raw reply
* Re: [PATCH] Documentation - pt-BR.
From: Thiago Farina @ 2009-10-08 3:25 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <20091008001248.GS32702@genesis.frugalware.org>
Hi Miklos,
On Wed, Oct 7, 2009 at 9:12 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Tue, Oct 06, 2009 at 12:20:00PM -0300, Thiago Farina <tfransosi@gmail.com> wrote:
>> > $ ls -1 /etc/asciidoc/lang-*
>> > /etc/asciidoc/lang-de.conf
>> > /etc/asciidoc/lang-en.conf
>> > /etc/asciidoc/lang-es.conf
>> > /etc/asciidoc/lang-fr.conf
>> > /etc/asciidoc/lang-hu.conf
>> > /etc/asciidoc/lang-ru.conf
>> In my system I only have installed lang-es.conf, how I could install the others?
>
> This is with asciidoc 8.5.0, I guess you have a bit older version.
I will check :)
>
>> Sure, I made the lang-pt-BR.conf, and I sent it to asciidoc@googlegroups.com.
>
> Great, then sooner or later you could have those 'NAME' and 'SYNOPSIS'
> strings localised. Till then, I would suggest having them in English -
> git typically supports building with older asciidoc versions.
My patch was added to the trunk -
http://hg.sharesource.org/asciidoc/rev/5bc014ab7c52.
^ permalink raw reply
* Re: [JGIT PATCH] The default encoding for reading commits is UTF-8 rather than system default
From: Shawn O. Pearce @ 2009-10-08 4:16 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <1254930273-1796-1-git-send-email-constantine.plotnikov@gmail.com>
Constantine Plotnikov <constantine.plotnikov@gmail.com> wrote:
> See man git-commit (the section "DISCUSSION"), for justification why
> UTF-8 should be used. Note that this was already correctly implemented
> in ObjectWriter.writeCommit(...) method. But Commit.decode() was not
> implemented in the same way for some reason.
Commit predates that encoding code in ObjectWriter.writeCommit and
it looks like we just forgot to go back and fix it. A very old bug.
Since our move to the Eclipse Foundation we really need to follow
their IP process, which for non-committers means creating a new bug
in their Bugzilla system:
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit
See also:
http://wiki.eclipse.org/EGit/Contributor_Guide#Contributing_Patches
> .../tst/org/spearce/jgit/lib/T0003_Basic.java | 3 +++
> .../src/org/spearce/jgit/lib/Commit.java | 18 +++++++-----------
> 2 files changed, 10 insertions(+), 11 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/3] completion: fix alias listings with newlines
From: Shawn O. Pearce @ 2009-10-08 4:29 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <4ACCE417.5080907@gmail.com>
Stephen Boyd <bebarino@gmail.com> wrote:
> Johannes Sixt wrote:
> > Is it necessary to change the body of the loop? Your version spawns two
> > processes on each iteration, while the original spawned no processes.
Yes, we should try to avoid spawning a process here, it fires on
each completion attempt if I recall.
> Maybe a better solution would be to add --keys-only or something to
> git-config?
Or a format string with a language based escape like for-each-ref
supports? Might make it easier to use git config in scripts if we
can write things like:
git config --format='$data{%(key)}=%(value);' --perl
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/3] completion: add dirstat and friends to diff options
From: Shawn O. Pearce @ 2009-10-08 4:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SZEDER G??bor, Stephen Boyd, git
In-Reply-To: <7vmy42pzvc.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> SZEDER G??bor <szeder@ira.uka.de> writes:
>
> > On Wed, Oct 07, 2009 at 01:48:51AM -0700, Stephen Boyd wrote:
> >> + --dirstat --dirstat= --dirstat-by-file
> >> + --dirstat-by-file= --cumulative
> >
> > I'm a bit puzzled by having both --dirstat and --dirstat=, and
> > --dirstat-by-file and --dirstat-by-file=. How do we complete similar
> > long options, where an argument and hence the = char is optional?
>
> A similar example in "git init" completion (--shared vs --shared=) already
> exists, no?
I'm not sure why this is. It may just be historical accident,
completing --shared vs. --shared= is ambiguous so you would need
to type out the = anyway before trying to complete a value.
IIRC --shared= came about after --shared and its possible we just
added the new option and didn't notice the duplicate.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-send-email.perl: Fold long header lines to 78 chars
From: Junio C Hamano @ 2009-10-08 5:02 UTC (permalink / raw)
To: Joe Perches; +Cc: git, Jay Soffian
In-Reply-To: <1254759898.1799.449.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
> Some MTAs reject or filter long header lines which can
> be generated if the cc list is only a few entries.
>
> Fold long header lines to 78 chars to be more rfc compliant.
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index dd821f7..cb8b48b 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -835,10 +870,10 @@ sub send_message
> $gitversion = Git::version();
> }
>
> - my $cc = join(", ", unique_email_list(@cc));
> + @cc = unique_email_list(@cc);
> my $ccline = "";
> - if ($cc ne '') {
> - $ccline = "\nCc: $cc";
> + if (@cc gt 0) {
"gt"? I think you meant (@cc > 0) but you can also say "if (@cc) {" which
would most clearly convey what you want to say..
> + $ccline = fold_header("\nCc: ", ", ", @cc);
> }
> my $sanitized_sender = sanitize_address($sender);
> make_message_id() unless defined($message_id);
> @@ -976,7 +1011,7 @@ X-Mailer: git-send-email $gitversion
> if ($smtp_server !~ m#^/#) {
> print "Server: $smtp_server\n";
> print "MAIL FROM:<$raw_from>\n";
> - print "RCPT TO:".join(',',(map { "<$_>" } @recipients))."\n";
> + print fold_header("RCPT TO:", ",", map { "<$_>" } @recipients)."\n";
I do not think this hunk is correct.
Shouldn't we be rather repeating "RCPT TO: " for each recipient, as
RFC2821 4.1.1.3 says (this is an issue with the original code)? I do not
think SMTP's "RCPT TO" command has the notion of continuation line used
for the payload (i.e. RFC 2822 Internet Message Format), and folding the
line is a new bug this patch introduces.
> } else {
> print "Sendmail: $smtp_server ".join(' ',@sendmail_parameters)."\n";
> }
^ permalink raw reply
* [Gitweb-caching][RFC] Major updates - kernel.org updated
From: J.H. @ 2009-10-08 4:51 UTC (permalink / raw)
To: Git Mailing List
Evening everyone,
Thought I'd give a heads up that I finally sat down and did some major
updates to my version of the gitweb caching code (as opposed to Lea's,
which I still have plans to integrate with mine in the near future).
That said this brings the base up to mainline, which is about a 2 or 3
year jump in code, it updates a number of elements in the caching engine
itself and I went ahead and ripped out the file breakout that I had
done initially.
New things known to work:
- Snapshots are fully working, and passing through the caching
engine
- Binary files now output correctly when your using blob_plain,
this is also passing correctly through the caching engine.
I'm sure there is a plethora of other things that have been fixed or broken.
So I'm going to re-open the can of worms over caching again, and see
what it would take to get this merged into mainline. Obviously a patch
clean-up (my tree is a lot more organic than mainline) is needed, but I
thought I'd try and get an idea of where I need to start steering all of
this.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: [PATCH] git-send-email.perl: Fold long header lines to 78 chars
From: Joe Perches @ 2009-10-08 5:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jay Soffian
In-Reply-To: <7vd44yo4uz.fsf@alter.siamese.dyndns.org>
On Wed, 2009-10-07 at 22:02 -0700, Junio C Hamano wrote:
> Joe Perches <joe@perches.com> writes:
> > Some MTAs reject or filter long header lines which can
> > be generated if the cc list is only a few entries.
> > Fold long header lines to 78 chars to be more rfc compliant.
> >
> > - my $cc = join(", ", unique_email_list(@cc));
It's probably better/simpler to not use fold_header and
just do the same join as "my $to"
my $cc = join(",\n\t", unique_email_list(@cc));
> > if ($smtp_server !~ m#^/#) {
> > print "Server: $smtp_server\n";
> > print "MAIL FROM:<$raw_from>\n";
> > - print "RCPT TO:".join(',',(map { "<$_>" } @recipients))."\n";
> > + print fold_header("RCPT TO:", ",", map { "<$_>" } @recipients)."\n";
> I do not think this hunk is correct.
> Shouldn't we be rather repeating "RCPT TO: " for each recipient, as
> RFC2821 4.1.1.3 says (this is an issue with the original code)?
Looks like you're right.
Want a new patch or will you fix both issues?
I suggest using the same join as "To:" for "Cc:" and
multiple single line "RCPT TO:"s.
^ permalink raw reply
* What's cooking in git.git (Oct 2009, #01; Wed, 07)
From: Junio C Hamano @ 2009-10-08 6:33 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 integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planeed changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
We are in pre-release feature freeze. 'next' will hold topics meant for
1.6.6 and 1.7.0.
Tonight's tip of 'master' is 1.6.5-rc3.
--------------------------------------------------
[New Topics]
* ch/am-header (2009-09-25) 2 commits
(merged to 'next' on 2009-09-25 at f86e197)
+ git-am: force egrep to use correct characters set
+ git-am: fixed patch_format detection according to RFC2822
* dk/blame-el (2009-09-29) 1 commit
- git-blame.el: Change how blame information is shown.
* ef/msvc-noreturn (2009-09-30) 2 commits
(merged to 'next' on 2009-10-07 at 66137a0)
+ add NORETURN_PTR for function pointers
+ increase portability of NORETURN declarations
jk: This is the latest round and I think should be ready for at least
'next' (maybe even 'master' as it is really about the build and not about
functionality).
* ef/msys-imap (2009-10-03) 7 commits
- mingw: enable OpenSSL
- mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
- imap-send: provide fall-back random-source
- imap-send: build imap-send on Windows
- imap-send: fix compilation-error on Windows
- imap-send: use run-command API for tunneling
- imap-send: use separate read and write fds
jk: This is from an RFC which has generated some comments. He should be
posting another round soon. 'pu' at best.
* fc/mutt-alias (2009-09-30) 1 commit
(merged to 'next' on 2009-10-07 at df7ac20)
+ send-email: fix mutt regex for grouped aliases
jk: Latest round that addressed comments. Ready for 'next' if not
'master'.
* jk/reflog-date (2009-09-24) 1 commit
(merged to 'next' on 2009-09-29 at 43d444a)
+ improve reflog date/number heuristic
* jn/gitweb-patch (2009-09-30) 1 commit
- gitweb: Do not show 'patch' link in 'commit' view for merges
jk: After some comments with Jakub, I think the code is right but he
promised a re-roll with more in the commit message.
* mr/gitweb-snapshot (2009-09-26) 2 commits
- gitweb: append short hash ids to snapshot files
- gitweb: check given hash before trying to create snapshot
jk: He posted a v5 of his series. I didn't look at it closely, but Jakub
ack'd it.
* mr/instaweb-cgid (2009-09-26) 1 commit
(merged to 'next' on 2009-09-29 at 3524604)
+ instaweb: support mod_cgid for apache2
* tf/doc-pt-br (2009-09-23) 1 commit
- Documentation: update pt-BR
The current AsciiDoc may barf on NOME and SINOPSE, as pt_BR language
definition is not widely distributed yet (it just hit the development
tree). Need to revert these headings (or change the length of the section
underlines to match the length of translated names).
* jc/pretty-lf (2009-10-04) 1 commit
- Pretty-format: %[+-]x to tweak inter-item newlines
I am not happy with this one yet. I am contemplating to introduce a new
syntax "%[magic(param)<anything>%]" to generalize expressions of this and
line wrapping features in an extensible way.
* js/log-rewrap (2008-11-10) 3 commits
. Add "%w" to pretty formats, which rewraps the commit message
- Add strbuf_add_wrapped_text() to utf8.[ch]
- print_wrapped_text(): allow hard newlines
... and the first two from this series will be useful to implement an
example magic "wrap", e.g. "%{wrap(i,j,w)%s%+b%]".
* jg/log-format-body-indent (2009-09-19) 1 commit
. git-log --format: Add %B tag with %B(x) option
I think we should redo this on top of the first two patches from
js/log-rewrap series; %B(x) is just a special case %B(x,x,0), no? If a
magic value 0 (or negative) given to wrap-width does not disable wrapping,
we probably should make it so. I merged this to 'pu' but then ejected it
because it seems to break at least t6006.
* bg/rebase-reword (2009-10-07) 1 commit
- Teach 'rebase -i' the command "reword"
* js/diff-verbose-submodule (2009-10-04) 1 commit
- Add the --submodule-summary option to the diff option family
Dscho sounded like he has some corrections after list comments, but I did
not pick up his interdiff in the middle.
--------------------------------------------------
[Stalled]
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-08-30 at b6455c2)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jh/cvs-helper (2009-08-18) 8 commits
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
- Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)
Builds on db/vcs-helper. There is a re-roll planned.
* ne/rev-cache (2009-09-07) 7 commits
- support for commit grafts, slight change to general mechanism
- support for path name caching in rev-cache
- full integration of rev-cache into git, completed test suite
- administrative functions for rev-cache, start of integration into git
- support for non-commit object caching in rev-cache
- basic revision cache system, no integration or features
- man page and technical discussion for rev-cache
I merged this to 'pu' but then ejected it because it seems to break at
least t6001.
--------------------------------------------------
[Cooking]
* jl/submodule-add-noname (2009-09-22) 1 commit
- git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
* jc/fix-tree-walk (2009-09-14) 9 commits
- read-tree --debug-unpack
- unpack-trees.c: look ahead in the index
- unpack-trees.c: prepare for looking ahead in the index
- traverse_trees(): handle D/F conflict case sanely
- more D/F conflict tests
- tests: move convenience regexp to match object names to test-lib.sh
- unpack_callback(): use unpack_failed() consistently
- unpack-trees: typofix
- diff-lib.c: fix misleading comments on oneway_diff()
This is my replacement for Linus's lt/maint-traverse-trees-fix patch. It
is not so much as a counter-proposal; I originally thought it might make
sense to walk the index and drive the walker to return the entries from
trees to match entries from the index, but I ended up doing pretty much
what Linus outlined --- walk the trees, and have the index walker follow
it. It turned out that the index side also needed some hairy look-ahead,
and I am only half satisfied with the current status of the series.
To fix the resolve merge regression seen in t6035, git-merge-resolve needs
to be rewritten not to use the one-path-at-a-time "git merge-index".
* jp/fetch-tag-match (2009-09-17) 1 commit
- fetch: Speed up fetch by rewriting find_non_local_tags
I did not have much energy left while dealing with the "fix-tree-walk"
series, so I just queued this without reading nor thinking about it very
much. I personally liked my version that had far smaller number of lines
changed (which means I can be fairly certain that it did not introduce any
regression), but perhaps the majorly rewritten logic this patch gives us
may be easier to follow and maintain. We'll see.
* jc/maint-blank-at-eof (2009-09-15) 0 commits.
(this branch uses jc/maint-1.6.0-blank-at-eof.)
The series does not have a commit of its own but is a preparation for
merging the original jc/1.6.0-maint-blank-at-eof topic to 'maint' and then
'master'. It is a fix for longstanding bug and 1.6.5 will not contain
this topic.
* db/vcs-helper-rest (2009-09-03) 6 commits
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
(this branch is used by jh/cvs-helper.)
This holds the remainder of the db/vcs-helper topic that has already
merged for 1.6.5.
* jh/notes (2009-09-12) 13 commits
- Selftests verifying semantics when loading notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- notes.[ch] fixup: avoid old-style declaration
- Teach notes code to free its internal data structures on request.
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
(this branch uses sr/gfi-options.)
Rerolled and queued.
* jn/gitweb-show-size (2009-09-07) 1 commit
- gitweb: Add 'show-sizes' feature to show blob sizes in tree view
* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
. Prepare 'traverse_trees()' for D/F conflict lookahead
Ejected from 'pu' (see jc/fix-tree-walk above).
* jc/maint-1.6.0-blank-at-eof (2009-09-14) 15 commits.
(merged to 'next' on 2009-09-15 at 9cbfa00)
+ diff -B: colour whitespace errors
+ diff.c: emit_add_line() takes only the rest of the line
+ diff.c: split emit_line() from the first char and the rest of the line
+ diff.c: shuffling code around
+ diff --whitespace: fix blank lines at end
(merged to 'next' on 2009-09-07 at 165dc3c)
+ core.whitespace: split trailing-space into blank-at-{eol,eof}
+ diff --color: color blank-at-eof
+ diff --whitespace=warn/error: fix blank-at-eof check
+ diff --whitespace=warn/error: obey blank-at-eof
+ diff.c: the builtin_diff() deals with only two-file comparison
+ apply --whitespace: warn blank but not necessarily empty lines at EOF
+ apply --whitespace=warn/error: diagnose blank at EOF
+ apply.c: split check_whitespace() into two
+ apply --whitespace=fix: detect new blank lines at eof correctly
+ apply --whitespace=fix: fix handling of blank lines at the eof
(this branch is used by jc/maint-blank-at-eof.)
This is a fix for an ancient bug (or inconsistent set of features); the
topic is based on an ancient codebase and is designed to be merged
upwards. jc/maint-blank-at-eof serves that purpose.
Will not be in 1.6.5.
* jn/gitweb-blame (2009-09-01) 5 commits
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-09-07 at 3622199)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame.
* sr/gfi-options (2009-09-06) 6 commits
(merged to 'next' on 2009-09-07 at 5f6b0ff)
+ fast-import: test the new option command
+ fast-import: add option command
+ fast-import: test the new feature command
+ fast-import: add feature command
+ fast-import: put marks reading in it's own function
+ fast-import: put option parsing code in separate functions
(this branch is used by jh/notes.)
Ping?
* nd/sparse (2009-08-20) 19 commits
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-09-05) 5 commits
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-09-07 at 8a7c563)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
* jc/1.7.0-status (2009-09-05) 4 commits
(merged to 'next' on 2009-09-06 at 19d4beb)
+ status: typo fix in usage
(merged to 'next' on 2009-08-22 at b3507bb)
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
(merged to 'next' on 2009-08-22 at 5106de8)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-08-30 at 0623572)
+ diff.c: fix typoes in comments
(merged to 'next' on 2009-08-27 at 81fb2bd)
+ Make test case number unique
(merged to 'next' on 2009-08-02 at 9c08420)
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits
(merged to 'next' on 2009-08-02 at 38b82fe)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* cc/reset-merge (2009-09-16) 4 commits
. reset: add test cases for "--merge-safe" option
. reset: add option "--merge-safe" to "git reset"
. reset: use "unpack_trees()" directly instead of "git read-tree"
. reset: add a few tests for "git reset --merge"
* cc/sequencer-rebase-i (2009-08-28) 15 commits
. rebase -i: use "git sequencer--helper --cherry-pick"
. sequencer: add "--cherry-pick" option to "git sequencer--helper"
. sequencer: add "do_commit()" and related functions working on "next_commit"
. pick: libify "pick_help_msg()"
. revert: libify cherry-pick and revert functionnality
. rebase -i: use "git sequencer--helper --fast-forward"
. sequencer: let "git sequencer--helper" callers set "allow_dirty"
. sequencer: add "--fast-forward" option to "git sequencer--helper"
. sequencer: add "do_fast_forward()" to perform a fast forward
. rebase -i: use "git sequencer--helper --reset-hard"
. sequencer: add "--reset-hard" option to "git sequencer--helper"
. sequencer: add "reset_almost_hard()" and related functions
. rebase -i: use "git sequencer--helper --make-patch"
. sequencer: add "make_patch" function to save a patch
. sequencer: add "builtin-sequencer--helper.c"
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)
From: Johannes Schindelin @ 2009-10-08 6:49 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <7viqeqjsx6.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 7 Oct 2009, Junio C Hamano wrote:
> * sr/gfi-options (2009-09-06) 6 commits
> (merged to 'next' on 2009-09-07 at 5f6b0ff)
> + fast-import: test the new option command
> + fast-import: add option command
> + fast-import: test the new feature command
> + fast-import: add feature command
> + fast-import: put marks reading in it's own function
> + fast-import: put option parsing code in separate functions
> (this branch is used by jh/notes.)
>
> Ping?
Shawn, last time I heard of this issue, it was stuck in your review queue.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox