* [JGIT PATCH] The default encoding for reading commits is UTF-8 rather than system default
From: Constantine Plotnikov @ 2009-10-07 15:44 UTC (permalink / raw)
To: git; +Cc: Constantine Plotnikov
When reading commits the system default encoding was used if no encoding
was specified in the commit. The patch modifies test to add a check that
commit message was encoded correctly (the test fails on old implementation
if system encoding is not UTF-8) and fixes Commit.decode() method to use
UTF-8 is encoding is not specified in the commit object.
Signed-off-by: Constantine Plotnikov <constantine.plotnikov@gmail.com>
---
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.
.../tst/org/spearce/jgit/lib/T0003_Basic.java | 3 +++
.../src/org/spearce/jgit/lib/Commit.java | 18 +++++++-----------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java
index c2b1b91..4702aaf 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java
@@ -348,6 +348,9 @@ public void test023_createCommitNonAnullii() throws IOException {
commit.setMessage("\u00dcbergeeks");
ObjectId cid = new ObjectWriter(db).writeCommit(commit);
assertEquals("4680908112778718f37e686cbebcc912730b3154", cid.name());
+ Commit loadedCommit = db.mapCommit(cid);
+ assertNotSame(loadedCommit, commit);
+ assertEquals(commit.getMessage(), loadedCommit.getMessage());
}
public void test024_createCommitNonAscii() throws IOException {
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java
index 030d4a4..933b929 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java
@@ -299,17 +299,13 @@ private void decode() {
br.read(readBuf);
int msgstart = readBuf.length != 0 ? ( readBuf[0] == '\n' ? 1 : 0 ) : 0;
- if (encoding != null) {
- // TODO: this isn't reliable so we need to guess the encoding from the actual content
- author = new PersonIdent(new String(rawAuthor.getBytes(),encoding.name()));
- committer = new PersonIdent(new String(rawCommitter.getBytes(),encoding.name()));
- message = new String(readBuf,msgstart, readBuf.length-msgstart, encoding.name());
- } else {
- // TODO: use config setting / platform / ascii / iso-latin
- author = new PersonIdent(new String(rawAuthor.getBytes()));
- committer = new PersonIdent(new String(rawCommitter.getBytes()));
- message = new String(readBuf, msgstart, readBuf.length-msgstart);
- }
+ // If encoding is not specified, the default for commit is UTF-8
+ if (encoding == null) encoding = Constants.CHARSET;
+
+ // TODO: this isn't reliable so we need to guess the encoding from the actual content
+ author = new PersonIdent(new String(rawAuthor.getBytes(),encoding.name()));
+ committer = new PersonIdent(new String(rawCommitter.getBytes(),encoding.name()));
+ message = new String(readBuf,msgstart, readBuf.length-msgstart, encoding.name());
} catch (IOException e) {
e.printStackTrace();
} finally {
--
1.6.1.2
^ permalink raw reply related
* [JGIT PATCH v2] The default encoding for reading commits is UTF-8 rather than system default
From: Constantine Plotnikov @ 2009-10-07 16:26 UTC (permalink / raw)
To: git; +Cc: Constantine Plotnikov
When reading commits the system default encoding was used if no encoding
was specified in the commit. The patch modifies test to add a check that
commit message was encoded correctly (the test fails on old implementation
if system encoding is not UTF-8) and fixes Commit.decode() method to use
UTF-8 is encoding is not specified in the commit object.
Signed-off-by: Constantine Plotnikov <constantine.plotnikov@gmail.com>
---
This version is over eclipse.org packages.
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.
.../tst/org/eclipse/jgit/lib/T0003_Basic.java | 3 +++
.../src/org/eclipse/jgit/lib/Commit.java | 18 +++++++-----------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0003_Basic.java b/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0003_Basic.java
index 98fb794..f3bc9b1 100644
--- a/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0003_Basic.java
+++ b/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0003_Basic.java
@@ -348,6 +348,9 @@ public void test023_createCommitNonAnullii() throws IOException {
commit.setMessage("\u00dcbergeeks");
ObjectId cid = new ObjectWriter(db).writeCommit(commit);
assertEquals("4680908112778718f37e686cbebcc912730b3154", cid.name());
+ Commit loadedCommit = db.mapCommit(cid);
+ assertNotSame(loadedCommit, commit);
+ assertEquals(commit.getMessage(), loadedCommit.getMessage());
}
public void test024_createCommitNonAscii() throws IOException {
diff --git a/org.eclipse.jgit/src/org/eclipse/jgit/lib/Commit.java b/org.eclipse.jgit/src/org/eclipse/jgit/lib/Commit.java
index b2cf9b1..430cddc 100644
--- a/org.eclipse.jgit/src/org/eclipse/jgit/lib/Commit.java
+++ b/org.eclipse.jgit/src/org/eclipse/jgit/lib/Commit.java
@@ -299,17 +299,13 @@ private void decode() {
br.read(readBuf);
int msgstart = readBuf.length != 0 ? ( readBuf[0] == '\n' ? 1 : 0 ) : 0;
- if (encoding != null) {
- // TODO: this isn't reliable so we need to guess the encoding from the actual content
- author = new PersonIdent(new String(rawAuthor.getBytes(),encoding.name()));
- committer = new PersonIdent(new String(rawCommitter.getBytes(),encoding.name()));
- message = new String(readBuf,msgstart, readBuf.length-msgstart, encoding.name());
- } else {
- // TODO: use config setting / platform / ascii / iso-latin
- author = new PersonIdent(new String(rawAuthor.getBytes()));
- committer = new PersonIdent(new String(rawCommitter.getBytes()));
- message = new String(readBuf, msgstart, readBuf.length-msgstart);
- }
+ // If encoding is not specified, the default for commit is UTF-8
+ if (encoding == null) encoding = Constants.CHARSET;
+
+ // TODO: this isn't reliable so we need to guess the encoding from the actual content
+ author = new PersonIdent(new String(rawAuthor.getBytes(),encoding.name()));
+ committer = new PersonIdent(new String(rawCommitter.getBytes(),encoding.name()));
+ message = new String(readBuf,msgstart, readBuf.length-msgstart, encoding.name());
} catch (IOException e) {
e.printStackTrace();
} finally {
--
1.6.1.2
^ permalink raw reply related
* gitweb calls the project ".git"
From: Lars Rasmusson @ 2009-10-07 16:31 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
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?)
Thanks for any quick ideas, cheers,
/Lars
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2427 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] completion: fix alias listings with newlines
From: Stephen Boyd @ 2009-10-07 18:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <4ACC6055.1070204@viscovery.net>
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.
>
> You can avoid the pipeline (i.e. yet another process) using a "here-string":
>
> local i aliases=$(git --git-dir="$(__gitdir)" config -z \
> --get-regexp "alias\..*" 2>/dev/null)
> while IFS= read -rd '' i; do
> i="${i#alias.}"
> echo "${i/ */}" # could be: echo "${i%% *}"
> done <<< "$aliases"
>
> but I don't know how well bash handles variable values with embedded NULs.
I can't get the above snippet to work, but maybe I'm doing something wrong.
I had a problem with the newline between the key and the value. bash
gives me the whole line in the loop, but when I try to trim it $i is
treated as two values. I couldn't figure out any other way to do it,
besides piping $i to cut or tr.
Maybe a better solution would be to add --keys-only or something to
git-config?
^ permalink raw reply
* 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
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