* Re: How to merge git://repo.or.cz/git-gui into git.git
From: Yin Ping @ 2007-10-30 8:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Peter Baumann, git
In-Reply-To: <7vmyu1s1qt.fsf@gitster.siamese.dyndns.org>
>
> Actually, subtree strategy was designed to allow merging back
> and forth. But the result, as it _is_ a merge, will not omit
> any commit from the history from both branches.
>
>
Can git-log be more clever so that it can recognize a subtree merge
and show only logs related to the subtree?
Another suggestion is that the commit msg for subtree merge should be
more accurate such as " Merge branch master of <repos> into direcotry
<dir> of branch <branch>"
--
franky
^ permalink raw reply
* Re: [PATCH 01/10] push: change push to fail if short refname does not exist
From: Steffen Prohaska @ 2007-10-30 8:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwst5m2eq.fsf@gitster.siamese.dyndns.org>
On Oct 30, 2007, at 9:29 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> Pushing a short refname used to create a new ref on on the
>> remote side if it did not yet exist. If you specified the wrong
>> branch accidentally it was created. A safety valve that pushes
>> only existing branches may help to avoid errors.
>
> On the other hand, if you specified a wrong branch that exists
> on the remote end accidentally, it still was pushed. Do we want
> to have a new "--i-really-want-to-push" option to make it safer?
Maybe not a bad idea ;)
But not as a command line flag but after printing the results
of a '--dry-run' and than asking the user for confirmation:
"do you want to push this?".
> I do not think so. Why should a new branch be treated any
> differently?
Because "updating an existing branch" and "creating a new branch"
are two slightly different tasks.
If git provides a way to make this difference explicit, it
would be safer to use.
> Will drop 1/10 and 2/10 for now.
Then they'll be dropped and I'll rely on the the --dry-run flag.
Or someone else needs to step in and support my point.
Steffen
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Junio C Hamano @ 2007-10-30 8:56 UTC (permalink / raw)
To: Peter Karlsson
Cc: Alex Riesen, Steffen Prohaska, Shawn O. Pearce, Git Mailing List
In-Reply-To: <Pine.LNX.4.62.0710291357420.23695@perkele.intern.softwolves.pp.se>
Peter Karlsson <peter@softwolves.pp.se> writes:
> Alex Riesen:
>
>> Because you do not send changes to a _server_. There is no
>> server. There is just another repo. Hence just "push"
>
> Fine. "Send to repository", then. My point is that if "push" is a
> technical term, then it doesn't belong in the GUI, and if it isn't,
> then it should be translated like any other UI element.
Why doesn't a "technical term" belong in the GUI in the first
place?
If majority of people who use git know and use the term "push"
to describe that concept, certainly they will be the people from
whom the new people who start to use git (either from command
line or from GUI) get help. Why do you want to have them use
different language to make the communication more difficult?
^ permalink raw reply
* Re: [PATCH 01/10] push: change push to fail if short refname does not exist
From: Junio C Hamano @ 2007-10-30 9:22 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <AD10F15D-0F77-42BB-86CA-6404063C784B@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> On Oct 30, 2007, at 9:29 AM, Junio C Hamano wrote:
> ...
>> Will drop 1/10 and 2/10 for now.
>
> Then they'll be dropped and I'll rely on the the --dry-run flag.
>
> Or someone else needs to step in and support my point.
Yup, you exactly got what I meant by "for now". I reserve the
right to be convinced and converted later ;-).
^ permalink raw reply
* Missing MIME-headers in git-email-tool ..
From: Matti Aarnio @ 2007-10-30 9:53 UTC (permalink / raw)
To: git
The git-send-email does send posts without any sort of MIME labeling:
From: / To: removed
Subject: [PATCH 0/2] Blackfin I2C/TWI driver updates
Date: Tue, 30 Oct 2007 17:33:15 +0800
Message-Id: <1193736797-9005-1-git-send-email-bryan.wu@analog.com>
X-Mailer: git-send-email 1.5.3.4
Precedence: bulk
which per MIME rules means that the message in question is equivalent
to one with header labels:
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
What would be a problem ? Some of us have names that are encoded
in 8-bit form, and some receiving systems get all mighty upset when
they receive unlabelled email carry 8-bit encoded texts.
(Thanks to chinese and russian spammers..)
Now if the git-send-email would add following three lines in all
outgoing email headers, things would be 99% correct for a long time..
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
The potential incorrectness is with UTF-8 encoded names.
Even then it probably is merely nuisance and not real delivery
preventing detail.
/Matti Aarnio -- one of <postmaster @ vger.kernel.org>
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Johannes Schindelin @ 2007-10-30 9:58 UTC (permalink / raw)
To: Peter Karlsson
Cc: Alex Riesen, Steffen Prohaska, Shawn O. Pearce, Git Mailing List
In-Reply-To: <Pine.LNX.4.62.0710291357420.23695@perkele.intern.softwolves.pp.se>
Hi,
On Mon, 29 Oct 2007, Peter Karlsson wrote:
> Alex Riesen:
>
> > Because you do not send changes to a _server_. There is no server. There is
> > just another repo. Hence just "push"
>
> Fine. "Send to repository", then. My point is that if "push" is a technical
> term, then it doesn't belong in the GUI, and if it isn't, then it should be
> translated like any other UI element.
Come on. "Byte" is a technical term, too, and only the French translate
it. Same goes for "Computer". There is a point where hiding the truth
from the user becomes silly. This is it.
Ciao,
Dscho
^ permalink raw reply
* Re: remote#branch
From: Johannes Schindelin @ 2007-10-30 10:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Junio C Hamano, Jan Hudec, Petr Baudis,
Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710292150400.30120@woody.linux-foundation.org>
Hi,
On Mon, 29 Oct 2007, Linus Torvalds wrote:
> On Tue, 30 Oct 2007, Theodore Tso wrote:
>
> > Quick! Which of the URL-like strings follow the URL quoting rules,
> > and which ones don't?
>
> Quick! WHO THE F*CK CARES?
I second this.
Should we -- ever -- encounter problems with the way we do things, we can
still fix it. So far, our "inconsistent" behaviour has not given me
grief.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-10-30 10:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxztm2dx.fsf@gitster.siamese.dyndns.org>
On Oct 30, 2007, at 9:29 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> git push now allows you pushing a couple of branches that have
>> advanced, while ignoring all branches that have no local changes,
>> but are lagging behind their matching remote refs. This is done
>> without reporting errors.
>>
>> Thanks to Junio C. Hamano <gitster@pobox.com> for suggesting to
>> report in the summary that refs have been ignored.
>
> I do not think this is a good idea at all. Furthermore, I never
> suggested anything about summary.
Yeah, sorry. You only asked if the summary does mention
something; not suggesting it should do so.
> You are robbing the
> information from the pusher which ones are pushed and which ones
> are left behind.
Absolutely; because the branches left behind are not
interesting. The remote already is ahead of the local
branches. The local branches are just left were they are. They
have no new information on them. Forcing an push would _rewind_
the remote without adding anything to it.
If you really intended to do a rewind you should have passed
'--force' in the first place and my report would never be
printed.
> It simply is insane to make this strange rule 10/10 introduces
> the default behaviour. It is too specific to a particular
> workflow (that is, working with a shared central repository,
> having many locally tracking branches that are not often used
> and become stale, and working on only things to completion
> between pushes).
I don't think its very strange behaviour if you see it in the
light of what the user wants to achieve. We are talking about
the case were only fast forward pushes are allowed. So, we
only talk about a push that has the goal of adding new local
changes to the remote. The user says "git push" and means
push my new local changes to the remote.
Unfortunately, the remote may have advanced differently from
the local branch, and the push must fail because someone needs
to merge first. git push recommends to do a pull and retry, which
is the right thing to do.
My strange rule 10/10 adds a check that verifies if the local
side has something interesting to push. Only in this case a
pull make sense. If you do not have something new, a pull will
be a fast-forward, and just a waste of time.
In this light I think the current behaviour is insane, because
it asks the user to spend time on things that do not add any
value. No new commits, no new information, no need to merge, no
need to push again, no need to report errors ...
> I think we could live with an optional behaviour, in addition to
> the current "matching refs" behaviour, that is "matching refs,
> ignoring strict ancestors", though, but I doubt it is worth the
> addition.
... just ignore strict ancestors by default.
Steffen
^ permalink raw reply
* Re: broken strings in localization (was: How to run git-gui always in English?)
From: Christian Stimming @ 2007-10-30 10:16 UTC (permalink / raw)
To: git; +Cc: prohaska, spearce, johannes.schindelin
Steffen Prohaska wrote:
> And it's even worse. An error in the localization can completely
> break git-gui. Apparently the German localization included in
> msysgit's Git-1.5.3-preview20071019.exe _is_ broken (see
> attached png).
>
> Shouldn't the localization code be a bit more fault tolerant?
Thanks for this error description. However, this isn't a fault of the
localization per se; rather, it's a bad side-effects of git-gui using
its own script po2msg.sh instead of gettext's msgfmt to prepare
translations for inclusion in the program - and additionally the fact
that this po2msg.sh script is used by the creator of the setup.exe,
whereas the translators use msgfmt which will not exhibit this error.
Here's what happened: The program code changed from using the string
"Prune from %s" to "Prune from" (just like program code changes
often). Before, the translation had a translation like this:
msgid "Prune from %s"
msgstr "Abschneiden von %s"
or similar, in any case with the including "%s". After the string
changed in the program, the next update of the translation file will
record the fact that the original string changed by changing the
translation like this:
#, fuzzy
msgid "Prune from"
msgstr "Abschneiden von %s"
Note that the msgstr-translation has not been changed yet - this can
only be done by a human. For that reason, the update inserted the
"fuzzy" marker. Here's where the error came in: All strings marked as
"fuzzy" MUST NOT BE USED by msgfmt! And git-gui's script po2msg.sh
doesn't adhere to this rule. Boo, that's why such erroneous
translations made it into the msgcat catalog.
In other words: The tcl msgcat procedure is the wrong end to deal with
that problem. Instead, those string argument checks should be done
when "compiling" the foo.po files into the foo.msg files. And that's
precisely what the msgfmt program is for: It correctly ignores all
"fuzzy" strings and it additionally checks the %s et al string formats
for correct translation (when used with the "-c" switch, as the
"shift-V" command in emacs po-mode or any other po file editor will
use).
@Dscho: That's why I'm rather unhappy with the addition of the
po2msg.sh script. Not adhering to the "fuzzy" marker is clearly a bug
and needs to be fixed there, but additionally you lose all format
checking that msgfmt gives to you. Syntax errors in the translator's
foo.po file should really be dealt with at msgfmt compile time, not
later at runtime. That's the whole point of that compile step.
Regards,
Christian
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-10-30 10:26 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <52171BF7-50E2-473E-A0BD-CB64D38FD502@zib.de>
Steffen Prohaska wrote:
>
> My strange rule 10/10 adds a check that verifies if the local
> side has something interesting to push. Only in this case a
> pull make sense. If you do not have something new, a pull will
> be a fast-forward, and just a waste of time.
>
Err... fast-forward pulls are not a waste of time. What a strange
notion. Perhaps I misunderstood, but this sentence jumped out at
me and immediately got filed under "decidedly odd".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Missing MIME-headers in git-email-tool ..
From: Johannes Schindelin @ 2007-10-30 10:31 UTC (permalink / raw)
To: Matti Aarnio; +Cc: git
In-Reply-To: <20071030095338.GZ6372@mea-ext.zmailer.org>
Hi,
On Tue, 30 Oct 2007, Matti Aarnio wrote:
> The git-send-email does send posts without any sort of MIME labeling:
>
> From: / To: removed
>
> Subject: [PATCH 0/2] Blackfin I2C/TWI driver updates
> Date: Tue, 30 Oct 2007 17:33:15 +0800
> Message-Id: <1193736797-9005-1-git-send-email-bryan.wu@analog.com>
> X-Mailer: git-send-email 1.5.3.4
> Precedence: bulk
>
>
> which per MIME rules means that the message in question is equivalent
> to one with header labels:
>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
AFAICT MIME headers are only added when needed. (But that might only
apply to format-patch; however, if you signed off with your name, all
should be well.)
> Now if the git-send-email would add following three lines in all
> outgoing email headers, things would be 99% correct for a long time..
>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=ISO-8859-15
> Content-Transfer-Encoding: 8BIT
No.
Not at all.
ISO-8859-15 is just as wrong as ASCII. You just forget about the majority
of the population on this earth. That is just as arrogant and snobbish as
the people who thought that ASCII would be good enough for everyone.
Ciao,
Dscho
^ permalink raw reply
* Re: broken strings in localization (was: How to run git-gui always in English?)
From: Johannes Schindelin @ 2007-10-30 10:45 UTC (permalink / raw)
To: Christian Stimming; +Cc: git, prohaska, spearce
In-Reply-To: <20071030111626.0mbeh417tw4wos0s@webmail.tu-harburg.de>
Hi,
On Tue, 30 Oct 2007, Christian Stimming wrote:
> Note that the msgstr-translation has not been changed yet - this can
> only be done by a human. For that reason, the update inserted the
> "fuzzy" marker. Here's where the error came in: All strings marked as
> "fuzzy" MUST NOT BE USED by msgfmt! And git-gui's script po2msg.sh
> doesn't adhere to this rule. Boo, that's why such erroneous translations
> made it into the msgcat catalog.
My bad. I thought I handled that, but obviously I did not. Will fix.
Ciao,
Dscho
^ permalink raw reply
* [BUG] remote.c/match_explicit() ... NULL pointer dereferenciation (git 1.5.3.4)
From: Melchior FRANZ @ 2007-10-30 10:44 UTC (permalink / raw)
To: git
Hi,
I'm mucking around with git while implementing a simple, flat
CVS gateway. For tests I created a local remote clone via
"git remote add -f -t master -m master origin /local/path"
(as described on the git-remote man-page). When running a
(wrong) command like "git push origin foo", whereby "foo"
is nowhere defined in the refspec list:
[remote "origin"]
url = /local/path
fetch = +refs/heads/master:refs/remotes/origin/master
push = +master:refs/heads/sync
then git-send-pack segfaults in remote.c/count_refspec_match
in the strlen() function, because "pattern" contains garbage.
And this is because in match_explicit() we have these lines:
if (!matched_src)
errs = 1;
if (dst_value == NULL)
dst_value = matched_src->name;
<<- gdb prints from here
and with the unknown refspec "foo" both dst_value and matched_src
are zero:
(gdb) print dst_value
$1 = 0x0
(gdb) print *rs
$2 = {
force = 0,
pattern = 0,
src = 0x808d680 "foo",
dst = 0x0
}
(gdb) print matched_src
$3 = (struct ref *) 0x0
(gdb) print dst_value
$4 = 0x34 <Address 0x34 out of bounds>
No idea, why the NULL-pointer dereferenciation doesn't segfault
right away, but assigns 0x34 to dst_value. Compiler bug?
m.
Spec:
Linux 2.6.23.1 x86/P4
gcc 4.2.1 (SUSE Linux) (openSuSE 10.3)
libc 2.6.1 (20070803)
git 1.5.3.4 (compiled with -g -O0)
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-10-30 10:53 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <472706DB.1040106@op5.se>
On Oct 30, 2007, at 11:26 AM, Andreas Ericsson wrote:
> Steffen Prohaska wrote:
>> My strange rule 10/10 adds a check that verifies if the local
>> side has something interesting to push. Only in this case a
>> pull make sense. If you do not have something new, a pull will
>> be a fast-forward, and just a waste of time.
>
> Err... fast-forward pulls are not a waste of time. What a strange
> notion. Perhaps I misunderstood, but this sentence jumped out at
> me and immediately got filed under "decidedly odd".
If the local branch is a strict ancestor, a pull is only
interesting if you want to start to work on such a branch
locally. But pull is a waste of time if you're only goal is to
push. Push suggests to pull first. So you pull; and then you
push again; and the result on the remote is the same. Only
the error message is gone that could have been avoided in the
first place. -> waste of time.
If you _pull_ it would be interesting to learn that you probably
want to merge to more than the current local branch. At that
time you expressed the intention to integrate new changes from
the remote. And it's probably a good idea to integrate changes
on all local branches that are set up to automatically merge
from the same remote you just pulled.
But if you push you want to push. You'd probably only interested
in pulls that add immediate value to the push. That is if the
result of a subsequent push modified the remote.
Steffen
^ permalink raw reply
* [GIT-GUI PATCH 0/3] po2msg fixes
From: Johannes Schindelin @ 2007-10-30 11:24 UTC (permalink / raw)
To: stimming, spearce, git
Hi,
this series of 3 patches fixes the following:
- fuzzy translations are ignored
- empty translations are ignored
- the --statistics option is implemented
Ciao,
Dscho
^ permalink raw reply
* [GIT-GUI PATCH 1/3] po2msg: ignore entries marked with "fuzzy"
From: Johannes Schindelin @ 2007-10-30 11:24 UTC (permalink / raw)
To: stimming, spearce, git
In-Reply-To: <Pine.LNX.4.64.0710301122300.4362@racer.site>
As Christian Stimming pointed out, entries which are "fuzzy" need to
be checked by human translators, and cannot be used.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
po/po2msg.sh | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/po/po2msg.sh b/po/po2msg.sh
index da0765d..48a2669 100644
--- a/po/po2msg.sh
+++ b/po/po2msg.sh
@@ -48,12 +48,16 @@ for {set i 1} {$i < $argc} {incr i} {
}
proc flush_msg {} {
- global msgid msgstr mode lang out
+ global msgid msgstr mode lang out fuzzy
if {![info exists msgid] || $mode == ""} {
return
}
set mode ""
+ if {$fuzzy == 1} {
+ set fuzzy 0
+ return
+ }
if {$msgid == ""} {
set prefix "set ::msgcat::header"
@@ -64,6 +68,7 @@ proc flush_msg {} {
puts $out "$prefix \"[u2a $msgstr]\""
}
+set fuzzy 0
foreach file $files {
regsub "^.*/\(\[^/\]*\)\.po$" $file "$output_directory\\1.msg" outfile
set in [open $file "r"]
@@ -73,7 +78,11 @@ foreach file $files {
set mode ""
while {[gets $in line] >= 0} {
if {[regexp "^#" $line]} {
- flush_msg
+ if {[regexp ", fuzzy" $line]} {
+ set fuzzy 1
+ } else {
+ flush_msg
+ }
continue
} elseif {[regexp "^msgid \"(.*)\"$" $line dummy match]} {
flush_msg
--
1.5.3.4.1423.g7c7a7
^ permalink raw reply related
* [GIT-GUI PATCH 2/3] po2msg: ignore untranslated messages
From: Johannes Schindelin @ 2007-10-30 11:24 UTC (permalink / raw)
To: stimming, spearce, git
In-Reply-To: <Pine.LNX.4.64.0710301122300.4362@racer.site>
Do not generate translations when the translated message is empty.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
po/po2msg.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/po/po2msg.sh b/po/po2msg.sh
index 48a2669..91d420b 100644
--- a/po/po2msg.sh
+++ b/po/po2msg.sh
@@ -62,6 +62,9 @@ proc flush_msg {} {
if {$msgid == ""} {
set prefix "set ::msgcat::header"
} else {
+ if {$msgstr == ""} {
+ return
+ }
set prefix "::msgcat::mcset $lang \"[u2a $msgid]\""
}
--
1.5.3.4.1423.g7c7a7
^ permalink raw reply related
* [GIT-GUI PATCH 3/3] po2msg: actually output statistics
From: Johannes Schindelin @ 2007-10-30 11:25 UTC (permalink / raw)
To: stimming, spearce, git
In-Reply-To: <Pine.LNX.4.64.0710301122300.4362@racer.site>
The "--statistics" option was ignored so far; no longer. Now we have
a message similar to that of msgfmt. (Untranslated, though ;-)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
po/po2msg.sh | 23 +++++++++++++++++++++--
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/po/po2msg.sh b/po/po2msg.sh
index 91d420b..78e49cc 100644
--- a/po/po2msg.sh
+++ b/po/po2msg.sh
@@ -26,11 +26,17 @@ proc u2a {s} {
set output_directory "."
set lang "dummy"
set files [list]
+set show_statistics 0
# parse options
-for {set i 1} {$i < $argc} {incr i} {
+for {set i 0} {$i < $argc} {incr i} {
set arg [lindex $argv $i]
- if {$arg == "--statistics" || $arg == "--tcl"} {
+ if {$arg == "--statistics"} {
+ incr show_statistics
+ continue
+ }
+ if {$arg == "--tcl"} {
+ # we know
continue
}
if {$arg == "-l"} {
@@ -49,12 +55,14 @@ for {set i 1} {$i < $argc} {incr i} {
proc flush_msg {} {
global msgid msgstr mode lang out fuzzy
+ global translated_count fuzzy_count not_translated_count
if {![info exists msgid] || $mode == ""} {
return
}
set mode ""
if {$fuzzy == 1} {
+ incr fuzzy_count
set fuzzy 0
return
}
@@ -63,15 +71,20 @@ proc flush_msg {} {
set prefix "set ::msgcat::header"
} else {
if {$msgstr == ""} {
+ incr not_translated_count
return
}
set prefix "::msgcat::mcset $lang \"[u2a $msgid]\""
+ incr translated_count
}
puts $out "$prefix \"[u2a $msgstr]\""
}
set fuzzy 0
+set translated_count 0
+set fuzzy_count 0
+set not_translated_count 0
foreach file $files {
regsub "^.*/\(\[^/\]*\)\.po$" $file "$output_directory\\1.msg" outfile
set in [open $file "r"]
@@ -113,3 +126,9 @@ foreach file $files {
close $out
}
+puts $show_statistics
+if {$show_statistics} {
+ puts [concat "$translated_count translated messages, " \
+ "$fuzzy_count fuzzy ones, " \
+ "$not_translated_count untranslated ones."]
+}
--
1.5.3.4.1423.g7c7a7
^ permalink raw reply related
* Re: Missing MIME-headers in git-email-tool ..
From: Matti Aarnio @ 2007-10-30 11:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710301028360.4362@racer.site>
On Tue, Oct 30, 2007 at 10:31:41AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 30 Oct 2007, Matti Aarnio wrote:
>
> > The git-send-email does send posts without any sort of MIME labeling:
> >
> > From: / To: removed
> >
> > Subject: [PATCH 0/2] Blackfin I2C/TWI driver updates
> > Date: Tue, 30 Oct 2007 17:33:15 +0800
> > Message-Id: <1193736797-9005-1-git-send-email-bryan.wu@analog.com>
> > X-Mailer: git-send-email 1.5.3.4
> > Precedence: bulk
> >
> >
> > which per MIME rules means that the message in question is equivalent
> > to one with header labels:
> >
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=US-ASCII
> > Content-Transfer-Encoding: 7bit
>
> AFAICT MIME headers are only added when needed. (But that might only
> apply to format-patch; however, if you signed off with your name, all
> should be well.)
I wish that were true.. We (VGER's Postmasters that is) would not see
so much rejections from all over the places... Would it motivate you
if we sent all GIT caused ones to you ?
The MIME headers should always be added. The charset= -value can be
debated about. If the headers are not there, and VGER is sending email
to system which does not report capability of receiving 8BITMIME, then
the message will be converted to QUOTED-PRINTABLE (and headers be added)
Worst that can happen when the message is mis-labelled as US-ASCII and
still contains 8-bit chars is not outright rejection, but stripping the
8th-bit off..
> > Now if the git-send-email would add following three lines in all
> > outgoing email headers, things would be 99% correct for a long time..
> >
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=ISO-8859-15
> > Content-Transfer-Encoding: 8BIT
>
> No.
>
> Not at all.
>
> ISO-8859-15 is just as wrong as ASCII. You just forget about the majority
> of the population on this earth. That is just as arrogant and snobbish as
> the people who thought that ASCII would be good enough for everyone.
I wish the world was perfect and everybody would use single unified charset..
which obviously is not true. However as the kernel sources DO NOT SPECIFY
COMMENT CHARSET, using ISO-8859-15 is LESS WRONG than picking UTF-8.
The reasoning here is that getting the email thru is more important than
absolutely correct labels.
If you wish, you may scan the message content at first to determine if it does
indeed include characters outside the US-ASCII range. You may even determine
if the charset in question is likely UTF-8 instead of one of the Latins.
Whatever you do, do put the MIME labels in place.
> Ciao,
> Dscho
/Matti Aarnio -- one of <postmaster @ vger.kernel.org>
^ permalink raw reply
* Re: Missing MIME-headers in git-email-tool ..
From: Johannes Schindelin @ 2007-10-30 12:07 UTC (permalink / raw)
To: Matti Aarnio; +Cc: git
In-Reply-To: <20071030112750.GA6372@mea-ext.zmailer.org>
Hi,
[please Cc: me]
On Tue, 30 Oct 2007, Matti Aarnio wrote:
> On Tue, Oct 30, 2007 at 10:31:41AM +0000, Johannes Schindelin wrote:
>
> > On Tue, 30 Oct 2007, Matti Aarnio wrote:
> >
> > > The git-send-email does send posts without any sort of MIME labeling:
> > >
> > > From: / To: removed
> > >
> > > Subject: [PATCH 0/2] Blackfin I2C/TWI driver updates
> > > Date: Tue, 30 Oct 2007 17:33:15 +0800
> > > Message-Id: <1193736797-9005-1-git-send-email-bryan.wu@analog.com>
> > > X-Mailer: git-send-email 1.5.3.4
> > > Precedence: bulk
> > >
> > >
> > > which per MIME rules means that the message in question is equivalent
> > > to one with header labels:
> > >
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset=US-ASCII
> > > Content-Transfer-Encoding: 7bit
> >
> > AFAICT MIME headers are only added when needed. (But that might only
> > apply to format-patch; however, if you signed off with your name, all
> > should be well.)
>
> I wish that were true.. We (VGER's Postmasters that is) would not see
> so much rejections from all over the places... Would it motivate you
> if we sent all GIT caused ones to you ?
Heh.
I'm not a send-mail user myself, so I did not ever have any reason to dive
into its source code. Sorry.
I understand your pain. But as we assume UTF-8 in git if no other
encoding is selected, I think it makes more sense to default to UTF-8.
That said, I actually like the behaviour which I think is intended, to not
specify anything when the message can be interpreted as US-ASCII.
BTW I tried to find anything in the message you referenced which would
make it non-ASCII, but I did not find anything. But then, I am not
subscribed to the lkml, and can only get stripped down versions of the
mails via marc or kerneltrap.
Any send-email gurus want to join into this discussion?
Ciao,
Dscho
^ permalink raw reply
* Re: broken strings in localization (was: How to run git-gui always in English?)
From: Christian Stimming @ 2007-10-30 12:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, prohaska, spearce, nanako3
In-Reply-To: <Pine.LNX.4.64.0710301040490.4362@racer.site>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> Note that the msgstr-translation has not been changed yet - this can
>> only be done by a human. For that reason, the update inserted the
>> "fuzzy" marker. Here's where the error came in: All strings marked as
>> "fuzzy" MUST NOT BE USED by msgfmt! And git-gui's script po2msg.sh
>> doesn't adhere to this rule. Boo, that's why such erroneous translations
>> made it into the msgcat catalog.
>
> My bad. I thought I handled that, but obviously I did not. Will fix.
Patch looks good.
Note that "msgfmt" with the "-c" option still does more checking and
should probably be enabled by default. Currently I can use the "-c"
option by running make MSGFMT="msgfmt -c". We can just call msgfmt
always with the option -c (it was added in gettext-0.10.35 in 1998) so
that Shawn or everyone else gets immediate notice if there is a format
string problem in the file.
@nanako3: In particular, with the current git-gui.git master msgfmt
will complain about an error in ja.po, which is a rather tricky one.
(All the rest is fine.) The fix looks as follows (ignoring the
non-european characters):
diff --git a/po/ja.po b/po/ja.po
index f65e460..2713c9e 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -1781,3 +1781,3 @@ msgstr "??????????:"
msgid "%s ... %*i of %*i %s (%3i%%)"
-msgstr "%1$s ... %3$*i %4$s ?? %$2*i (%5$3i%%)"
+msgstr "%1$s ... %4$*i %6$s ?? %2$*i (%7$3i%%)"
Two errors: The easy one #1 is the confused '$' and '2' - the format
string in the middle should start with '%2$'. The difficult one #2 is
that one has to know that a format specification with a '*' (asterisk)
suddenly refers to *two* arguments instead of one, hence the suceeding
argument number is two higher instead of one. This way, the argument
numbers count up to 7.
Regards,
Christian
^ permalink raw reply related
* git-merge: inconsistent manual page.
From: Sergei Organov @ 2007-10-30 13:22 UTC (permalink / raw)
To: git
Hello,
git-merge has inconsistent manual page:
1. In the SYNOPSIS, there is [-m <msg>], but OPTIONS section lacks it.
The latter has just description of <msg>, suggesting it could be
used without -m, but SYNOPSIS doesn't reflect this.
BTW, git-merge options are described in
Documentation/merge-options.txt that is also used fot git-pull
options, and it's not clear for me if git-pull supports [-m
<msg>]. Does it?
2. In the SYNOPSIS, there is no <head> that is described in the
OPTIONS.
Overall, it seems that either SYNOPSIS should be changed (see patch
below), or historical syntax should be wiped from the manual page.
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index bca4212..0ea7aea 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git-merge' [-n] [--summary] [--no-commit] [--squash] [-s <strategy>]...
- [-m <msg>] <remote> <remote>...
+ [[-m] <msg>] [<head>] <remote> <remote>...
DESCRIPTION
-----------
--
Sergei.
^ permalink raw reply related
* Re: [PATCH 1/2] add throughput to progress display
From: Nicolas Pitre @ 2007-10-30 13:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6jdm2eb.fsf@gitster.siamese.dyndns.org>
On Tue, 30 Oct 2007, Junio C Hamano wrote:
> Very nice.
>
> I however wonder why this breaks t1004 when applied on top of
> lt/rename topic.
Well... sh*t happens.
Could you please simply amend [PATCH 1/2] with the patch below:
diff --git a/progress.c b/progress.c
index d2460dd..a388e54 100644
--- a/progress.c
+++ b/progress.c
@@ -143,6 +143,7 @@ void start_progress_delay(struct progress *progress, const char *title,
progress->last_percent = -1;
progress->delayed_percent_treshold = percent_treshold;
progress->delay = delay;
+ progress->throughput = NULL;
set_progress_signal();
}
@@ -160,5 +161,4 @@ void stop_progress(struct progress *progress)
}
clear_progress_signal();
free(progress->throughput);
- progress->throughput = NULL;
}
Nicolas
^ permalink raw reply related
* Re: [PATCH/RFC 0/3] faster inexact rename handling
From: Jeff King @ 2007-10-30 13:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Andy C, Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710292156580.30120@woody.linux-foundation.org>
On Mon, Oct 29, 2007 at 10:06:11PM -0700, Linus Torvalds wrote:
> Have you compared the results? IOW, does it find the *same* renames?
>From my limited testing, it generally finds the same pairs. However,
there are a number of renames that it _doesn't_ find, because they are
composed of "uninteresting" lines, dropping them below the minimum
score. Try (in git.git):
git-show --raw -M -l0 :/'Big tool rename'
with the old and new code. Pairs like Documentation/git-add-script.txt
-> Documentation/git-add.txt are not found, because the file is composed
almost entirely of boilerplate.
Moving the size normalization into the similarity engine should probably
fix that, and will let us compare old and new results more accurately.
I'll try to work on that.
> I'm a bit worried about the fact that you just pick a single (arbitrary)
> src/dst per fingerprint. Yes, it should be limited, but that seems to be a
> bit too *extremely* limited. But if it gives the same results in practice,
> maybe nobody cares?
Yes, I have not convinced myself yet that it's the right approach (but
it seemed like a good place to try first, for simplicity and speed). As
I noted, this approach seems to be a bit memory hungry on large, so I am
a bit concerned about increasing the size of the fingerprint_entry
structure. However, Andy's sampling approach might help fix that.
The current code also doesn't bother marking overflow, so common lines
get attributes to some random file (actually, worse than random: if a
bunch of files have the same common lines, _all_ of the lines will go to
the last file, which means we subtly favor renames from the end of the
input list). So probably it should be tested as-is, with an "overflow,
this line is too common to be interesting" bit, and with a small-ish
limit (I had at one point tried 5, but the implementation was naive and
too memory-hungry).
-Peff
^ permalink raw reply
* Re: [PATCH/RFC 0/3] faster inexact rename handling
From: Jeff King @ 2007-10-30 13:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, Andy C
In-Reply-To: <7vlk9lm2e5.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 30, 2007 at 01:29:22AM -0700, Junio C Hamano wrote:
> If it always gives the same results in practice, obviously
> nobody can even notice.
>
> However, merging this series to 'pu' breaks rebase-merge test
> t3402 among other things.
Yes, sorry, I meant to mention the test breakage in the cover letter
(which I think is just related to the size/score normalization). This is
not really meant for applying, but more for "this is taking me a lot
longer than I hoped, so here is what is happening and you might be
interested to comment." I'm not even sure it's pu material. :)
I will continue to refine it as I mentioned in the mail to Linus, but I
am open to suggestions.
-Peff
^ 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