* [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
* [PATCH] Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in example
From: Michael W. Olson @ 2007-10-30 13:53 UTC (permalink / raw)
To: git; +Cc: Michael W. Olson
---
Documentation/git-cvsexportcommit.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index 4c8d1e6..c3922f9 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -73,7 +73,7 @@ Merge one patch into CVS::
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
$ git-cvsexportcommit -v <commit-sha1>
-$ cvs commit -F .mgs <files>
+$ cvs commit -F .msg <files>
------------
Merge pending patches into CVS automatically -- only if you really know what you are doing::
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 1/2] add throughput to progress display
From: Nicolas Pitre @ 2007-10-30 13:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0710300935330.21255@xanadu.home>
On Tue, 30 Oct 2007, Nicolas Pitre wrote:
> 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:
Well that isn't enough. Please just scrap the whole thing as more
fundamental changes are needed. I'll send a new patch set when ready.
Nicolas
^ permalink raw reply
* Re: Missing MIME-headers in git-email-tool ..
From: Jeff King @ 2007-10-30 14:06 UTC (permalink / raw)
To: Matti Aarnio; +Cc: git
In-Reply-To: <20071030095338.GZ6372@mea-ext.zmailer.org>
On Tue, Oct 30, 2007 at 11:53:38AM +0200, 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
As Johannes explained, this happens only when there are no >7bit
characters in the email, so that interpretation is correct. Though I am
not opposed to sending those headers all the time, for clarity's sake.
> 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..)
Then git-send-email should be generating the MIME headers if there are
8-bit characters. Can you produce a test case where the most recent
version of git-send-email it does not?
> 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, this is just wrong. If git-send-email isn't adding headers when it
should to 8-bit output, then it's a bug. But papering over it with a
randomly chosen, possibly incorrect charset is not the right answer.
-Peff
^ permalink raw reply
* Re: Missing MIME-headers in git-email-tool ..
From: Jeff King @ 2007-10-30 14:09 UTC (permalink / raw)
To: Matti Aarnio; +Cc: git
In-Reply-To: <20071030140630.GC21342@coredump.intra.peff.net>
On Tue, Oct 30, 2007 at 10:06:30AM -0400, Jeff King wrote:
> > 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..)
>
> Then git-send-email should be generating the MIME headers if there are
> 8-bit characters. Can you produce a test case where the most recent
> version of git-send-email it does not?
Actually, btw, the code in question is from git-format-patch (it's just
that git-send-email doesn't add _any_ mime headers, as it assumes
git-format-patch either did it already, or none are needed).
-Peff
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Peter Karlsson @ 2007-10-30 13:34 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git
In-Reply-To: <13D1D3DD-9652-4097-8364-DEF4F26540D3@lrde.epita.fr>
Benoit SIGOURE:
> I think you can use grafts do achieve this.
That seems to work, but the grafts list doesn't seem to propagate when I
push/pull/clone. Is it possible to get that to work?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCH] no longer install git-svnimport, move to contrib/examples
From: Gerrit Pape @ 2007-10-30 14:24 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <7vy7dpy8qf.fsf@gitster.siamese.dyndns.org>
On Fri, Oct 26, 2007 at 12:30:16PM -0700, Junio C Hamano wrote:
> Steven Grimm <koreth@midwinter.com> writes:
> > Johannes Schindelin wrote:
> >>> I'm not sure these are worth fixing, I'd rather suggest to drop
> >>> git-svnimport in favor of git-svn, and not installing it in future
> >>> versions.
> >>>
> >> I already proposed this. The outcome was... silent.
> >
> > Me too, and same reaction.
> >
> > So I vote we interpret that as, "No objections from anyone."
>
> Likewise.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
.gitignore | 1 -
Documentation/cmd-list.perl | 1 -
Makefile | 3 +--
contrib/completion/git-completion.bash | 1 -
.../examples/git-svnimport.perl | 0
.../examples}/git-svnimport.txt | 0
6 files changed, 1 insertions(+), 5 deletions(-)
rename git-svnimport.perl => contrib/examples/git-svnimport.perl (100%)
rename {Documentation => contrib/examples}/git-svnimport.txt (100%)
diff --git a/.gitignore b/.gitignore
index 62afef2..8670081 100644
--- a/.gitignore
+++ b/.gitignore
@@ -128,7 +128,6 @@ git-status
git-stripspace
git-submodule
git-svn
-git-svnimport
git-symbolic-ref
git-tag
git-tar-tree
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index 1061fd8..8d21d42 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -185,7 +185,6 @@ git-status mainporcelain
git-stripspace purehelpers
git-submodule mainporcelain
git-svn foreignscminterface
-git-svnimport foreignscminterface
git-symbolic-ref plumbingmanipulators
git-tag mainporcelain
git-tar-tree plumbinginterrogators
diff --git a/Makefile b/Makefile
index 72f5ef4..eb98d91 100644
--- a/Makefile
+++ b/Makefile
@@ -225,8 +225,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-add--interactive.perl \
git-archimport.perl git-cvsimport.perl git-relink.perl \
- git-cvsserver.perl git-remote.perl \
- git-svnimport.perl git-cvsexportcommit.perl \
+ git-cvsserver.perl git-remote.perl git-cvsexportcommit.perl \
git-send-email.perl git-svn.perl
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e760930..599b2fc 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -346,7 +346,6 @@ __git_commands ()
ssh-*) : transport;;
stripspace) : plumbing;;
svn) : import export;;
- svnimport) : import;;
symbolic-ref) : plumbing;;
tar-tree) : deprecated;;
unpack-file) : plumbing;;
diff --git a/git-svnimport.perl b/contrib/examples/git-svnimport.perl
similarity index 100%
rename from git-svnimport.perl
rename to contrib/examples/git-svnimport.perl
diff --git a/Documentation/git-svnimport.txt b/contrib/examples/git-svnimport.txt
similarity index 100%
rename from Documentation/git-svnimport.txt
rename to contrib/examples/git-svnimport.txt
--
1.5.3.4
^ permalink raw reply related
* Re: Recording merges after repo conversion
From: Lars Hjemli @ 2007-10-30 14:29 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.62.0710301433150.652@perkele.intern.softwolves.pp.se>
On 10/30/07, Peter Karlsson <peter@softwolves.pp.se> wrote:
> Benoit SIGOURE:
>
> > I think you can use grafts do achieve this.
>
> That seems to work, but the grafts list doesn't seem to propagate when I
> push/pull/clone. Is it possible to get that to work?
>
No, the grafts file is purely local. To achieve your goal, you'd have
to 'git filter-branch' before pushing/cloning. But beware: this _will_
rewrite your current branch(es).
--
larsh
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 14:59 UTC (permalink / raw)
To: Tom Prince
Cc: Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071030053732.GA16963@hermes.priv>
On Tue, 30 Oct 2007, Tom Prince wrote:
> > The push url is generally written as
> >
> > repo.or.cz:/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
> >
> > Tough.
>
> But gitweb (on git.kernel.org and repo.or.cz) both give git:// locators.
Yes, for anonymous pulling.
The thing is, git takes something much more extended than a "RFC url".
We use pathnames. Not a "quoted mess". Regular, bog-standard, normal unix
pathnames.
On Windows, I assume (and hope) that git uses the native-style Windows
pathnames, and you can do "git pull d:\system\ugh" if you want to.
And I think we should care a whole lot about interacting with the *user*
and actual programs that git shares code with, than interacting with some
idiotic RFC that has absolutely zero to do with us, regardless of whether
we use the name "url" or not.
For example, the reason we use "host:/path" for pushing over ssh (and
pulling, for that matter), is that that's the same syntax that scp uses.
It's a natural fit. And I hope to God nobody seriously argues that we
shouldn't use regular pathnames on the local disk?
> > Quick! WHO THE F*CK CARES?
[ Btw, sorry for the french. I blame being tired and ina bad mood, but I
also blame the fact that I absolutely *detest* arguments based on
standards. If you cannot back it up with a real usage scenario, you
shouldn't even mention the standard ]
> So, how should git deal with
>
> git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
The way it has always cared. Git itself does no quoting what-so-ever
(except for the *argument* quoting etc that it needs).
Now, the *transport* back-end may end up quoting it, of course, the same
way it may end up using some random protocol. The user shouldn't care
about the implementation details!
In the case of the git transport, there is no quoting even by the
transport protocol. In the case of http, libcurl would hopefully quote for
us.
> compared to
>
> http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
No difference, what-so-ever, that I can see. Git doesn't quote it.
Notice how the fact that we use http:// doesn't actually mean that you can
feed the result to a web browser anyway? It's not like you get a "link"
that git follows. You get a name.
Yes, you can try to "co-locate" things so that something smart
disambiguates (maybe have an "index.html" file, so a web browser gets a
gitweb page, and git gets the raw data). But even then, notice how even
web browser will do the quoting for you: try
firefox "http://www.google.com/search?q=Html spaces"
just for fun.
Notice? The thing is, "strict RFC following" makes no sense:
- the git syntax is (and HAS TO BE to be user friendly) a real extension
on any "strict RFC URL" anyway, since it is a lot more important to
interact well with normal unix tools (ie use regular filenames, and use
the same syntax as "cp", "mv" and "find" etc uses!)
Ergo: we cannot and MUST NOT care about the "URL RFC" too deeply
anyway.
-
> Not that I care, but git should probably handle things consistently.
Git has been, and *is* entirely consistent. It uses convenient repo names.
If you don't want to call them url's, then call them "repository name".
Call them whatever. But they are 100% obvious, even if there are multiple
forms of them (and *none* of the forms do any quoting at all):
- <remote shorthand> ("origin")
- <path> ("../git.git")
- <host>:<path> ("master.kernel.org:/pub/scm/...")
- <protocol>://<host>/<path> ("git://repo.or.cz/...")
See? We may not follow RFC's, but we follow "easy to use".
And btw, that's really much much MUCH more important. It's why the git
config file is in a "ini"-like format. It's readable. It's not the insane
RFC crap that would result if somebody had decided that standards are more
important than being sane.
Linus
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johannes Schindelin @ 2007-10-30 15:05 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.62.0710301433150.652@perkele.intern.softwolves.pp.se>
Hi,
On Tue, 30 Oct 2007, Peter Karlsson wrote:
> Benoit SIGOURE:
>
> > I think you can use grafts do achieve this.
>
> That seems to work, but the grafts list doesn't seem to propagate when I
> push/pull/clone. Is it possible to get that to work?
No. Use filter-branch, and publish the cleaned up history (possibly as a
new branch/repo).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC 0/3] faster inexact rename handling
From: Linus Torvalds @ 2007-10-30 15:38 UTC (permalink / raw)
To: Jeff King; +Cc: git, Andy C, Junio C Hamano
In-Reply-To: <20071030134355.GA21342@coredump.intra.peff.net>
On Tue, 30 Oct 2007, Jeff King wrote:
>
> 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.
Ok, that does imply to me that we cannot just drop boilerplate text,
because the fact is, lots of files contain boilerplate, but people still
think they are "similar".
We do actually depend on the similarity analysis being "good" - because it
matters a lot for things like merging. The old code was actually very
careful indeed, and while it didn't care about things like the exact
*ordering* of lines (ie moving functions around in the same file resulted
in the *exact* same fingerprint for the file!) it cared about everything
else.
> 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.
Hmm. I hope that is sufficient. But I suspect it may well not be.
Especially since you ignore boiler-plate lines for *some* files but not
others (ie it depends on which file you happen to find it in first).
Linus
^ permalink raw reply
* Re: remote#branch
From: Tom Prince @ 2007-10-30 16:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710300738550.30120@woody.linux-foundation.org>
On Tue, Oct 30, 2007 at 07:59:45AM -0700, Linus Torvalds wrote:
> > Not that I care, but git should probably handle things consistently.
>
> Git has been, and *is* entirely consistent. It uses convenient repo names.
> If you don't want to call them url's, then call them "repository name".
> Call them whatever. But they are 100% obvious, even if there are multiple
> forms of them (and *none* of the forms do any quoting at all):
>
> - <remote shorthand> ("origin")
> - <path> ("../git.git")
> - <host>:<path> ("master.kernel.org:/pub/scm/...")
> - <protocol>://<host>/<path> ("git://repo.or.cz/...")
>
> See? We may not follow RFC's, but we follow "easy to use".
Well, only the last one actually looks like a URL, so that is the only this
discussion is about. I don't think anyone is suggesting that the first three
be changed at all. So, to use your terminology, git has a variety of ways to
specify a repo name, one of which happens to be a URL (or looks like one). The
suggestion is that we should make that way (and only that way) behave like a
RFC URL.
And git should be consistent with web browsers, automatically quoting things
it gets passed. I think the only point of contention is probably how to deal
with URLs that git receives that are already quoted.
1. We ignore the quoting and re-encode everything for the http transport.
2. We honour the encoding and decode everything for the git transport.
3. We handle git:// and http:// different, so that the three git:// URLs below
refer to different repositories, while the three http:// URLs give refer to
the same repository.
> > git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
>
> > http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
The third possibility is probably what we do now, which is why I am suggesting
git is inconsistent. The first will fall down when using a repository that is
colocated, and somebody copies a URL from the web browsers location bar (which
will be properly encoded). Which leaves the second.
Tom
^ permalink raw reply
* Re: [PATCH 0/4] Build in some more things
From: Daniel Barkalow @ 2007-10-30 16:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzly1nhmn.fsf@gitster.siamese.dyndns.org>
On Tue, 30 Oct 2007, Junio C Hamano wrote:
> I've merged this to 'pu', but honestly speaking, the conflicts
> are geting a bit more "interesting" than I care to keep
> repeating even with help from rerere, with four people
> simultaneously touching the neighbouring code in their topics.
I mostly actually care about [PATCH 1/4] which is also probably the
easiest to validate (since it really shouldn't change anything that
matters except to make things work in more cases). If I could get that in
early, I'd be fine with pushing the rest off until other people are out of
that code. The reason I care about 1/4 is that it also sets up an
extensive patch to make the fetch side of transport use the same git
connection for getting the initial list of remote refs and for fetching
their content (still with a second connection for auto-following tags,
since I couldn't figure out how to request more content after examining
some fetched content); this patch miraculously doesn't seem to
significantly conflict with anything currently in pu, and actually
provides a user-visible benefit (ssh transport with no special
infrastructure doesn't require typing the password multiple times for a
single logical operation most of the time).
On the other hand, [PATCH 2/4] might be worth floating earlier in pu,
since its conflicts are to simply remove all of the code that the other
patches update (since that code duplicates code in transport.c that can be
used instead).
For the builtin-send-pack stuff, I might as well redo the same logical
changes to the code once it settles down, since the edit sequence for 3/4
is really not all that well represented by diff, being very nearly "rename
a bunch of static globals; mark a bunch of things const; move a
function call down; split a function in half", and I can just redo that
after all the other changes.
> Topics involved are:
>
> ** db/remote-builtin (Mon Oct 29 22:03:42 2007 -0400) 4 commits
> . Use built-in send-pack.
> . Build-in send-pack, with an API for other programs to call.
> . Build-in peek-remote, using transport infrastructure.
> . Miscellaneous const changes and utilities
>
> * jk/send-pack (Thu Oct 18 02:17:46 2007 -0400) 2 commits
> + t5516: test update of local refs on push
> + send-pack: don't update tracking refs on error
>
> * js/forkexec (Fri Oct 19 21:48:06 2007 +0200)
> + Use start_command() in git_connect() instead of explicit
> fork/exec.
> + Change git_connect() to return a struct child_process instead of a
> pid_t.
>
> ** sp/push-refspec (Sun Oct 28 18:46:21 2007 +0100)
> . push: teach push to pass --verbose option to transport layer
> . push: use same rules as git-rev-parse to resolve refspecs
> . add ref_abbrev_matches_full_with_rev_parse_rules() comparing
> abbrev with full ref name
> . rename ref_matches_abbrev() to
> ref_abbrev_matches_full_with_fetch_rules()
>
> Could you please check the result after I push it out?
I agree with all of the conflict resolutions, although I didn't make sure
that parts that didn't get conflicts merged correctly (but, if it builds,
it's almost certainly right).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 0/4] Build in some more things
From: Daniel Barkalow @ 2007-10-30 16:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4726DC3D.2030202@viscovery.net>
On Tue, 30 Oct 2007, Johannes Sixt wrote:
> Daniel Barkalow schrieb:
> > The main effect of this series is removing the fork/exec from pushing via
> > the git protocol (aside from the later fork/exec in connect.c of course).
> >
> > It also heads off some tempting transport-related fetch bugs, which I will
> > not introduce in a later patch.
> >
> > * Miscellaneous const changes and utilities
> > Adds two small utility functions, and marks a bunch of stuff as const; the
> > const stuff is to keep builtin-fetch from getting messed up without a
> > warning, because it wants some lists not to change.
> >
> > * Build-in peek-remote, using transport infrastructure.
> > * Build-in send-pack, with an API for other programs to call.
> > * Use built-in send-pack.
>
> I assume this goes on top of current master or db/fetch-pack. The patches have
> some conflicts with js/forkexec (nothing serious, though). Maybe it makes
> sense to rebase on top of that.
Current master. As I said to Junio a moment ago (and forgot to cc you,
oops), I think 1/4 should go before js/forkexec, being trivial, and 2/4
should also, since it simply removes duplicate code that js/forkexec
updates; I should redo 3/4 after the code settles down, and 4/4 is trivial
but depends on 3/4.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 17:39 UTC (permalink / raw)
To: Tom Prince
Cc: Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071030160232.GB2640@hermes.priv>
On Tue, 30 Oct 2007, Tom Prince wrote:
> >
> > - <remote shorthand> ("origin")
> > - <path> ("../git.git")
> > - <host>:<path> ("master.kernel.org:/pub/scm/...")
> > - <protocol>://<host>/<path> ("git://repo.or.cz/...")
> >
> > See? We may not follow RFC's, but we follow "easy to use".
>
> Well, only the last one actually looks like a URL, so that is the only this
> discussion is about.
NO.
The thing is, we'd be much better off being consistent with OURSELVES than
with something else!
Nobody cares about git being consistent with a web browser. There is
nothing in common.
But I *do* care about git being consistent with itself. If I do
git clone /some/directory
and then decide that I want to generate a new pack and change it into
git clone file:///some/directory
I don't want to have to re-write the thing to quote differently!
The same very much goes for a path like
git://git.kernel.org/<path>
vs
master.kernel.org:<path>
because I will use the two interchangably. They *are* the same address,
except:
- the "git://" protocol is a bit faster, since the ssh connection
overhead is actually big enough to be quite noticeable.
- but I often use the master.kernel.org:<path> thing because there's a
mirroring delay that means that accessing it directly is sometimes
preferable.
See? THAT is where we need to be consistent: with our own paths!
[ And yes, I literally really do switch things around exactly like that
between ssh accesses and the git:// protocol. That was not a made-up
example, but real usage! ]
In contrast, nobody has _ever_ given a real technical reason to care about
the Web URL RFC at all.
Really. It's that simple: if you cannot argue for something without
pointing to an irrelevant standard, you really shouldn't argue for it in
the first place.
People who make decisions based on "it's a standard" make *sub*standard
decisions. The fact is, most standards are not worth even using as toilet
paper, because they were designed by some committee that wanted to reach
"consensus". That's just crap.
Linus
^ permalink raw reply
* Re: remote#branch
From: Matthieu Moy @ 2007-10-30 17:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tom Prince, Theodore Tso, Junio C Hamano, Jan Hudec,
Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710301037120.30120@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Nobody cares about git being consistent with a web browser.
Why do you keep talking about web browser?
URLs are _not_ a web-browser thing. A web browser is just _one_
example of program which uses URLs.
--
Matthieu
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 17:58 UTC (permalink / raw)
To: Matthieu Moy
Cc: Tom Prince, Theodore Tso, Junio C Hamano, Jan Hudec,
Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <vpq8x5kh4rr.fsf@bauges.imag.fr>
On Tue, 30 Oct 2007, Matthieu Moy wrote:
>
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > Nobody cares about git being consistent with a web browser.
>
> Why do you keep talking about web browser?
>
> URLs are _not_ a web-browser thing. A web browser is just _one_
> example of program which uses URLs.
I keep talking about a web browser, because THE ONLY POINT of following a
standard is to interoperate.
So if you cannot find something to interoperate with, why the hell would
you care about the standard?
So here's a question: why do people bother to quote irrelevant RFC's?
Following those RFC's would make git not interoperate WITH ITSELF, and use
illogically different formats for the same things.
So if you want to make that RFC have any relevance what-so-ever, then show
some interoperability issue. Which is why I'm bringing up a web browser:
that interop issue simply *does*not*exist*.
Why is that so hard to understand?
Linus
^ 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