* Re: pull-fetch-param.txt
From: Julian Phillips @ 2007-07-20 17:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git
In-Reply-To: <7vbqe7xbvq.fsf@assigned-by-dhcp.cox.net>
On Fri, 20 Jul 2007, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
>
>>> I'll check with the docbook-xsl Debian maintainer.
>>
>> The change in docbook-xsl was by intention, please see
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420114#22
>
> Hmph. Where does that leave us poor users who would want to
> support both 1.71 and 1.72, I wonder...
>
> Will they have the same revert in 1.73 for that House Sign, too?
It looks like they do, so perhaps we could just say that you will have
issues building the git docs with 1.72 and ignore my last patch?
(comparing http://docbook.xml-doc.org/snapshots/xsl/manpages/utility.xsl
which has today's date and uses . and \ against
http://docbook.sourceforge.net/release/xsl/1.72.0/manpages/utility.xsl
which uses U+2302 and U+2593)
--
Julian
---
Old MacDonald had an agricultural real estate tax abatement.
^ permalink raw reply
* [PATCH] git-submodule fixes for call to git config --get-regexp
From: Chris Larson @ 2007-07-20 17:23 UTC (permalink / raw)
To: git
Two minor git-submodule fixes:
* Escape !'s in the git config --get-regexp, so submodule paths can
contain them.
* Be more explicit about the value regex, otherwise things get confused if one
submodule name is a prefix of another (since --get-regexp can return
multiple values).
Signed-off-by: Chris Larson <clarson@kergoth.com>
--- git-submodule.sh.old 2007-07-20 10:13:22.578125000 -0700
+++ git-submodule.sh 2007-07-20 10:14:56.281250000 -0700
@@ -46,7 +46,8 @@ get_repo_base() {
#
module_name()
{
- name=$(GIT_CONFIG=.gitmodules git config --get-regexp
'^submodule\..*\.path$' "$1" |
+ path=$(echo "$1" | sed -e 's/\!/\\!/g')
+ name=$(GIT_CONFIG=.gitmodules git config --get-regexp
'^submodule\..*\.path$' "^$path$" |
sed -nre 's/^submodule\.(.+)\.path .+$/\1/p')
test -z "$name" &&
die "No submodule mapping found in .gitmodules for path '$path'"
--
Chris Larson - clarson at kergoth dot com
Dedicated Engineer - MontaVista - clarson at mvista dot com
Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Paolo Ciarrocchi @ 2007-07-20 17:32 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Christian Stimming, git
In-Reply-To: <20070720045510.GL32566@spearce.org>
On 7/20/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 19 Jul 2007, Christian Stimming wrote:
> >
> > > Does this implementation look okay?
> >
> > This is valuable work, but unfortunately, it does not follow the
> > recommendation in Documentation/SubmittingPatches at all.
> >
> > For starters, please send the patches inlined, one per mail. And you
> > might want to Cc the maintainer of git-gui (Shawn Pearce), too...
>
> I agree that internationalization of git-gui is worth doing.
> I've thought about working on it, but haven't yet because nobody
> else has seemed interested in having it done. Apparently someone
> is, so patches towards that end are most welcome.
Hi Shawn,
I volunteer to translate all the git-gui messages in Italian.
Just let me if you are interested and please give me an hint on how to
produce the translation so that you can incorporate it.
Thanks.
Regards,
--
Paolo
"Tutto cio' che merita di essere fatto,merita di essere fatto bene"
Philip Stanhope IV conte di Chesterfield
^ permalink raw reply
* Re: qgit: failed assertion involving unapplied stgit patches
From: Marco Costalba @ 2007-07-20 17:45 UTC (permalink / raw)
To: Yann DIRSON; +Cc: Marco Costalba, ydirson, git
In-Reply-To: <OF2EB5CD3A.5A6F9DF7-ONC125731E.004BD62A-C125731E.004FCEC9@sagem.com>
On 7/20/07, Yann DIRSON <yann.dirson@sagem.com> wrote:
>
> qgit 1.5.6 cannot show me the blame window for a given file, it complains
> with the following errors:
>
Hi Yann,
Yes. I confirm it's a bug.
A patch has been pushed both for qgit 1.5.6 and for new qgit4.
> However, I'm not sure why it walks this part of the tree, since the
> per-file history view does not show unapplied patches (it would be great to
> see them, though, as well as showing applied patches as such).
>
Regarding to show unapplied patch it seems a little bit difficult
because git-log /git-rev-list does not know them, after a quick look
it would seem easier to me to show applied patches as such...I will
investigate.
BTW if you use file history viewer I would suggest to switch to new
qgit4 (git://git.kernel.org/pub/scm/qgit/qgit4.git) it requires Qt4.3
but annotation is much more powerful, follows file renames (check
against vastly renamed git repository files) and it's an order of
magnitude faster.
Marco
^ permalink raw reply
* Re: pull-fetch-param.txt
From: Junio C Hamano @ 2007-07-20 18:01 UTC (permalink / raw)
To: Julian Phillips; +Cc: Gerrit Pape, git
In-Reply-To: <Pine.LNX.4.64.0707201758330.26817@reaper.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> On Fri, 20 Jul 2007, Junio C Hamano wrote:
> ...
>> Hmph. Where does that leave us poor users who would want to
>> support both 1.71 and 1.72, I wonder...
>>
>> Will they have the same revert in 1.73 for that House Sign, too?
>
> It looks like they do, so perhaps we could just say that you will have
> issues building the git docs with 1.72 and ignore my last patch?
That actually sounds a very tempting thing to do, especially
considering we are past -rc2.
^ permalink raw reply
* Re: [PATCH] git-submodule fixes for call to git config --get-regexp
From: Junio C Hamano @ 2007-07-20 18:07 UTC (permalink / raw)
To: Chris Larson; +Cc: git
In-Reply-To: <b6ebd0a50707201023h12ed3c61v31ccb2b356c1ee42@mail.gmail.com>
"Chris Larson" <clarson@kergoth.com> writes:
> Two minor git-submodule fixes:
> * Escape !'s in the git config --get-regexp, so submodule paths can
> contain them.
> --- git-submodule.sh.old 2007-07-20 10:13:22.578125000 -0700
> +++ git-submodule.sh 2007-07-20 10:14:56.281250000 -0700
> @@ -46,7 +46,8 @@ get_repo_base() {
> #
> module_name()
> {
> - name=$(GIT_CONFIG=.gitmodules git config --get-regexp
> '^submodule\..*\.path$' "$1" |
> + path=$(echo "$1" | sed -e 's/\!/\\!/g')
My first reaction was if it shouldn't be done for only the '!'
at the very beginning, to defeat "do_not_match" logic, but it
would not hurt if we have extra "\!" in the middle.
Once you introduce that sed to munge the path string, I suspect
you would also want and can afford to quote extended regular
expression metacharacters as well.
> + name=$(GIT_CONFIG=.gitmodules git config --get-regexp
> '^submodule\..*\.path$' "^$path$" |
> sed -nre 's/^submodule\.(.+)\.path .+$/\1/p')
> test -z "$name" &&
> die "No submodule mapping found in .gitmodules for path '$path'"
>
> --
> Chris Larson - clarson at kergoth dot com
> Dedicated Engineer - MontaVista - clarson at mvista dot com
> Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Junio C Hamano @ 2007-07-20 18:10 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Shawn O. Pearce, Johannes Schindelin, Christian Stimming, git
In-Reply-To: <4d8e3fd30707201032m1f9a0fe2jc74d2bea6c55f6ab@mail.gmail.com>
"Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
> I volunteer to translate all the git-gui messages in Italian.
>
> Just let me if you are interested and please give me an hint on how to
> produce the translation so that you can incorporate it.
Ah, am I expected to volunteer for Japanese part?
Unless yashi, yoshifuji, or nanako3 volunteer, although I do not
mind doing that myself, that is (if there are any Japanese
people I forgot, I apologize). I wonder how many people outside
English zone are regularly on the list...
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Brett Schwarz @ 2007-07-20 18:15 UTC (permalink / raw)
To: Christian Stimming; +Cc: git, Paul Mackerras, Shawn O. Pearce
[my apologies about top posting...my mail reader sucks]
Sure, I wasn't saying there would be for sure an advantage in re-using catalogs. That's why I said it *might* be worth looking into. Just a suggestion.
I agree that a glossary should be created first. That way, translators have a common set to work with.
Just a note about string substitution. msgcat has substitution built-in, so instead of this:
.mbar.apple add command -label [format [_ "About %s"] [appname]] \
You can do this:
.mbar.apple add command -label [_ "About %s" [appname]] \
Thanks,
--brett
----- Original Message ----
From: Christian Stimming <stimming@tuhh.de>
To: Brett Schwarz <brett_schwarz@yahoo.com>
Cc: git@vger.kernel.org; Paul Mackerras <paulus@samba.org>; Shawn O. Pearce <spearce@spearce.org>
Sent: Friday, July 20, 2007 2:03:54 AM
Subject: Re: [PATCH] Internationalization of git-gui
Quoting Brett Schwarz <brett_schwarz@yahoo.com>:
> Also, if the message catalogs are in a common location, then it
> might be worth looking into having gitk utilize these msg catalogs
> as well.
You mean you suggest to re-use existing msg catalogs in addition to
ones that are created on our own? Well, from the i18n coordination
work in another project (gnucash) I wouldn't expect any noticable
benefit from doing so. The re-usable parts of translations are rather
limited, basically limited to the standard menu entries and some more
single-word strings (Yes/No/Cancel...). But even then re-using other
translations might already decrease the quality of your own
translation, because other translators of packages might already have
chosen a different translation for e.g. "Cancel". For that reason I
strongly suggest using one single msg catalog for one single project,
so that the translator is even able to make sure each word is
translated into the same translation throughout the project.
(I also strongly suggest creating and translating a glossary of the
important terms before starting to translate the msg catalog itself,
but that's a different issue.)
> p.s. the frink tool (http://wiki.tcl.tk/2611) is supposed to be able
> to convert -text and -label switches to use msgcat...it might be
> worth looking into, instead of manually editing git-gui/gitk
Thanks for the pointer. However, the -text and -label switches can be
found and edited rather easily by keyboard macros and such. More
important than this are some changes that are necessary in order to
obtain strings that are actually translatable, such as
- .mbar.apple add command -label "About [appname]" \
+ .mbar.apple add command -label [format [_ "About %s"] [appname]] \
and you will agree those can only be done manually anyway.
Christian
____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
^ permalink raw reply
* [PATCH] Add --log-size to git log to print message size
From: Marco Costalba @ 2007-07-20 18:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
With this option git-log prints log message size
just before the corresponding message.
Porcelain tools could use this to speedup parsing
of git-log output.
Note that size refers to log message only. If also
patch content is shown its size is not included.
In case it is not possible to know the size upfront
size value is set to zero.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
This is take 3 of this patch. In this case has been clearly added that
diff content size is not included.
Documentation/git-log.txt | 7 +++++++
log-tree.c | 3 +++
revision.c | 4 ++++
revision.h | 1 +
4 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 63c1dbe..40b9a09 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -64,6 +64,13 @@ include::pretty-options.txt[]
--follow::
Continue listing the history of a file beyond renames.
+--log-size::
+ Before the log message print out its size in bytes. Intended
+ mainly for porcelain tools consumption. If git is unable to
+ produce a valid value size is set to zero.
+ Note that only message is considered, if also a diff is shown
+ its size is not included.
+
<paths>...::
Show only commits that affect the specified paths.
diff --git a/log-tree.c b/log-tree.c
index 8624d5a..2dc6b1b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -295,6 +295,9 @@ void show_log(struct rev_info *opt,
if (opt->add_signoff)
len = append_signoff(&msgbuf, &msgbuf_len, len,
opt->add_signoff);
+ if (opt->show_log_size)
+ printf("log size %i\n", len);
+
printf("%s%s%s", msgbuf, extra, sep);
free(msgbuf);
}
diff --git a/revision.c b/revision.c
index 28b5f2e..f1cbb1f 100644
--- a/revision.c
+++ b/revision.c
@@ -1149,6 +1149,10 @@ int setup_revisions(int argc, const
die("unknown date format %s", arg);
continue;
}
+ if (!strcmp(arg, "--log-size")) {
+ revs->show_log_size = 1;
+ continue;
+ }
/*
* Grepping the commit log
diff --git a/revision.h b/revision.h
index f46b4d5..98a0a8f 100644
--- a/revision.h
+++ b/revision.h
@@ -81,6 +81,7 @@ struct rev_info {
const char *log_reencode;
const char *subject_prefix;
int no_inline;
+ int show_log_size;
/* Filter by commit log message */
struct grep_opt *grep_filter;
--
1.5.3.rc2-dirty
^ permalink raw reply related
* Re: [PATCH] Internationalization of git-gui
From: Brett Schwarz @ 2007-07-20 18:34 UTC (permalink / raw)
To: Paolo Ciarrocchi, Shawn O. Pearce
Cc: Johannes Schindelin, Christian Stimming, git
After the glossary of terms has been create, it is easy to create the catalog file (assuming we use Tcl's standard mechanism). Each locale should have it's own file, named <locale_name>.msg (for example, es.msg for spanish). Inside that file, you just create entries for each glossary term (the below assumes that the msgcat namespace was imported):
mcset es Hello Hola
mcset es "Hello %s" "Hola %s"
.
.
.
You can find more out here if you like http://wiki.tcl.tk/msgcat
HTH,
--brett
----- Original Message ----
From: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
To: Shawn O. Pearce <spearce@spearce.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>; Christian Stimming <stimming@tuhh.de>; git@vger.kernel.org
Sent: Friday, July 20, 2007 10:32:24 AM
Subject: Re: [PATCH] Internationalization of git-gui
On 7/20/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 19 Jul 2007, Christian Stimming wrote:
> >
> > > Does this implementation look okay?
> >
> > This is valuable work, but unfortunately, it does not follow the
> > recommendation in Documentation/SubmittingPatches at all.
> >
> > For starters, please send the patches inlined, one per mail. And you
> > might want to Cc the maintainer of git-gui (Shawn Pearce), too...
>
> I agree that internationalization of git-gui is worth doing.
> I've thought about working on it, but haven't yet because nobody
> else has seemed interested in having it done. Apparently someone
> is, so patches towards that end are most welcome.
Hi Shawn,
I volunteer to translate all the git-gui messages in Italian.
Just let me if you are interested and please give me an hint on how to
produce the translation so that you can incorporate it.
Thanks.
Regards,
--
Paolo
"Tutto cio' che merita di essere fatto,merita di essere fatto bene"
Philip Stanhope IV conte di Chesterfield
-
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
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
^ permalink raw reply
* Re: [PATCH] git-submodule fixes for call to git config --get-regexp
From: Johannes Schindelin @ 2007-07-20 18:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Larson, git
In-Reply-To: <7vsl7jvthk.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 20 Jul 2007, Junio C Hamano wrote:
> "Chris Larson" <clarson@kergoth.com> writes:
>
> > + name=$(GIT_CONFIG=.gitmodules git config --get-regexp
> > '^submodule\..*\.path$' "^$path$" |
> > sed -nre 's/^submodule\.(.+)\.path .+$/\1/p')
I wonder why it is a regular expression to begin with, since we seem to
prefer shell patterns on paths.
However, _if_ we already go with regexps, why not just put it into the
"sed" call, which is _already_ there, and leave "git config" alone? IOW
call
git config --get-regexp '^submodule\..*\.path$' |
sed -nre 's/^submodule\.(.*$path.*)\.path .+$\1/p'
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Johannes Schindelin @ 2007-07-20 18:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paolo Ciarrocchi, Shawn O. Pearce, Christian Stimming, git
In-Reply-To: <7vodi7vtct.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 20 Jul 2007, Junio C Hamano wrote:
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
>
> > I volunteer to translate all the git-gui messages in Italian.
> >
> > Just let me if you are interested and please give me an hint on how to
> > produce the translation so that you can incorporate it.
>
> Ah, am I expected to volunteer for Japanese part?
>
> Unless yashi, yoshifuji, or nanako3 volunteer, although I do not
> mind doing that myself, that is (if there are any Japanese
> people I forgot, I apologize).
According to http://en.wikipedia.org/wiki/Japan, you forgot roughly
127,433,490 people ;-)
> I wonder how many people outside English zone are regularly on the
> list...
Here is one, but Christian already volunteered for the German part, I
understand...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add --log-size to git log to print message size
From: Johannes Schindelin @ 2007-07-20 18:41 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550707201115v2531434erd9e10a2b816a59bf@mail.gmail.com>
Hi,
On Fri, 20 Jul 2007, Marco Costalba wrote:
> This is take 3 of this patch. In this case has been clearly added that
> diff content size is not included.
Two concerns and a half:
- if you do not include the diff content size, don't you need to parse the
output anyway?
- what do you do if the underlying Git does not support --log-size? Exit?
- Would it not be much quicker to read the rev-list, and read messages
only on demand?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Paolo Ciarrocchi @ 2007-07-20 18:47 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Shawn O. Pearce, Christian Stimming, git
In-Reply-To: <Pine.LNX.4.64.0707201937080.14781@racer.site>
On 7/20/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
[...]
> > I wonder how many people outside English zone are regularly on the
> > list...
I tried to verify the results of the survey I sent out last year:
http://git.or.cz/gitwiki/GitSurvey
unfortunately that page seems to be full of spam.
Ciao,
--
Paolo
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Sam Ravnborg @ 2007-07-20 19:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Paolo Ciarrocchi, Shawn O. Pearce, Johannes Schindelin,
Christian Stimming, git
In-Reply-To: <7vodi7vtct.fsf@assigned-by-dhcp.cox.net>
On Fri, Jul 20, 2007 at 11:10:42AM -0700, Junio C Hamano wrote:
> I wonder how many people outside
> English zone are regularly on the list...
>From a scandinavian country (Denmark) but really I would never use
a translated version. So some decent amount of pressure would
be needed to convince me to add danish :-)
Sam
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Johannes Schindelin @ 2007-07-20 19:06 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Junio C Hamano, Shawn O. Pearce, Christian Stimming, git
In-Reply-To: <4d8e3fd30707201147l1f1797f8vefc712b2d3ae0f19@mail.gmail.com>
Hi,
On Fri, 20 Jul 2007, Paolo Ciarrocchi wrote:
> On 7/20/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> [...]
> > > I wonder how many people outside English zone are regularly on the
> > > list...
>
> I tried to verify the results of the survey I sent out last year:
> http://git.or.cz/gitwiki/GitSurvey
> unfortunately that page seems to be full of spam.
No longer. FWIW you can do it yourself: if you are logged in, there is a
"restore" link to the far right on the "Info" page of every wiki page.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Xudong Guan @ 2007-07-20 19:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Paolo Ciarrocchi, Shawn O. Pearce, Johannes Schindelin,
Christian Stimming, git
In-Reply-To: <7vodi7vtct.fsf@assigned-by-dhcp.cox.net>
On 11:10 Fri 20 Jul , Junio C Hamano wrote:
> I wonder how many people outside
> English zone are regularly on the list...
I am a Chinese, subscribed today.
Xudong
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Linus Torvalds @ 2007-07-20 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Simon 'corecode' Schubert, David Kastrup, git
In-Reply-To: <7vk5svxt1f.fsf@assigned-by-dhcp.cox.net>
On Fri, 20 Jul 2007, Junio C Hamano wrote:
>
> Using attribute that is detached from the content itself allows
> you to hoist that one bit one level up. By treating
> executable-ness not as part of content, we can compare two blobs
> with different executable bits cheaply. You can avoid
> descending into such a tree when comparing it with another tree
> that is different only by the "will-stay-when-emptied"-ness the
> same way.
Having thought about it a bit more, I would absolutely *detest* any kind
of "executable bit" like behaviour.
Why?
Merging. I think one of the fundamental issues in merging is that you do
it "in the working tree". This is something that pretty much *everybody*
else gets wrong, and it's somethign where git absolutely shines.
But git shines here exactly because git never tracks "history" or the
state in the tree, and only ever tracks things that are indubitably real
content. Which is why you never *ever* have to tell git about "I moved
file X to file Y" - because git only tracks things that it can see right
in front of it, in the tree.
The "sticky directory" bit simply would not be something like that. It
simply isn't "content", and as such, it should not be tracked. It's as
easy as that. We don't want a merge of two branches to have to specify any
extra data "outside" the tree as to how it should be merged.
So the issue about whether a directory *exists* or not can be merged (just
look at the tree), but the issue about whether the directory is supposed
to be sticky is something that you'd have to tell git about *outside* of
the tree, and that violates the whole point of working tree merges.
I do realize that if you use inferior operating systems, we already have
these kinds of "outside the tree" data entries, thanks to issues like
symlinks and normal file executable bits that you would have to explicitly
tell git about when you're working in a broken environment. So in that
sense, it wouldn't be anything technically new for git.
But that doesn't change the fundamental issue: the limitation with
executable bits and symlinks is a limitation of the broken environment,
not of git. But "directories stay around after the last file is gone" is
not that, it would simply be a design mistake in git itself.
There are other reasons to not do it. What about file renames? Maybe the
directory got *renamed*. From a pure content angle, this is "all the files
in that directory went away". If you have stupid rules like "directories
stay around even though all the files went away", you would again have
problems with this common case.
In other words: I don't care one whit about the whiners. What's MUCH more
important than some random whiny person saying "Daddy, daddy, I want a
pony" is whether you can afford to maintain that pony in the future. And
this pony is just stupid.
So here:
No, you cannot have a pony. NOT YOURS.
but I still think we should support the concept of importing things from
other systems, and thus eventually support empty directories. Just not any
crazy semantics with sticky histories.
Linus
PS. As usual, per-user or per-repository *local* attributes are something
else. They aren't "sticky history", they are just purely behavioural
defaults. Those kinds of things may make sense. But that's not a "tracking
content" issue.
^ permalink raw reply
* Re: [PATCH] Update listingblock monospace fix to support all docbook versions
From: Brian Gernhardt @ 2007-07-20 19:32 UTC (permalink / raw)
To: Julian Phillips; +Cc: Junio C Hamano, Fredrik Tolf, git
In-Reply-To: <20070720121153.23352.73276.julian@quantumfyre.co.uk>
On Jul 20, 2007, at 8:06 AM, Julian Phillips wrote:
> +while ($line = <>) {
> + $line =~ s/^#GIT#SET#MAN#FONT#/.ft/;
> + print $line;
> +}
Why not use `perl -pe "s/^#GIT#SET#MAN#FONT#/.ft/"` or an equivalent
sed command in the Makefile instead of having this as a separate script?
~~ Brian
^ permalink raw reply
* Re: [PATCH] Add --log-size to git log to print message size
From: Marco Costalba @ 2007-07-20 20:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707201939170.14781@racer.site>
On 7/20/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 20 Jul 2007, Marco Costalba wrote:
>
> > This is take 3 of this patch. In this case has been clearly added that
> > diff content size is not included.
>
> Two concerns and a half:
>
> - if you do not include the diff content size, don't you need to parse the
> output anyway?
>
First, dif content is included only when retrieving file history and
not to show revisions at startup that is the main use.
Second, also with diff content I don't parse the message because I
jump directly to the beginning of the diff and, yes, from there I
check for delimiting '\0', so I would say also in that case we have a
speedup, but it's not very important because we are talking of speed
up when you read thousands of revisions, few hundred (as typical in
file histories) are not a problem.
Also because with -p option git log becomes a real bottleneck.
> - what do you do if the underlying Git does not support --log-size? Exit?
>
If for "not support" you mean that underlying Git sets size at zero
(as allowed by specifications) this is of course handled: qgit falls
back on legacy '\0' search. BTW the currently published version does
exactly that, it has already the shortcut logic, but falls back always
on zero search because the modified git is _currently_ only on my hard
disk.
Otherwise, if you mean that git version is too old, in this case this
is caught by the git version check done always at startup.
Indeed I plan to add this feature only to new qgit4, will not be back
ported to stable qgit-1.5.6
> - Would it not be much quicker to read the rev-list, and read messages
> only on demand?
>
That's exactly what we are talking about ;-)
All the output of git-log (no more git-rev-list) is stored in memory
as a raw big binary blob, for quick retrieval, i.e. to avoid calling
an external git command process, but messages are not parsed until are
used. So _this_ is exactly the point of all this patch.
If you mean using git-rev-list without --header options then , also
not considering that currently we use git-log, the speed up is very
small and when you have to show something to the user you always need
to run a git command.
Perhaps this could be accepted (perhaps not ;-) for mouse browsing
through revisions, but what about sub string searching as example on
author or log title fields? probably it would became super slow also
for lists of only few hundred revs.
> Ciao,
> Dscho
Ciao
Marco
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Christian Stimming @ 2007-07-20 21:40 UTC (permalink / raw)
To: Brett Schwarz; +Cc: Paolo Ciarrocchi, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <772058.65660.qm@web38907.mail.mud.yahoo.com>
Am Freitag, 20. Juli 2007 20:34 schrieb Brett Schwarz:
> After the glossary of terms has been create, it is easy to create the
> catalog file (assuming we use Tcl's standard mechanism). Each locale should
> have it's own file, named <locale_name>.msg (for example, es.msg for
> spanish). Inside that file, you just create entries for each glossary term
> (the below assumes that the msgcat namespace was imported):
>
> mcset es Hello Hola
> mcset es "Hello %s" "Hola %s"
I beg your pardon, but I think you grossly misunderstood what I meant
by "glossary". So before we end up in further confusion, let me clarify how
the general translation approach works. I'll use gettext wording because
that's what I know (from being the i18n guy in the gnucash project), but you
can easily insert any other wording you like here.
#1 For the translation in general, there is the set of all user-visible
strings in the source language (here: english). In gettext terms this is
called the "PO template file", git-gui.pot, also called the message template
file. This set of to-be-translated strings needs to be extracted from the
source code, which can be done by the xgettext program.
#2 For each target language, there is a human-readable mapping file that maps
each source string (english) into the target language. In gettext terms this
is the "PO file", de.po and it.po and ja.po and whatnot, also called the
translation file. This is the *only* file translators actually work with.
Gettext uses its PO file format here and a plethora of different tools exist
to help translators editing these files. (Examples: emacs po-mode,
KBabel, ...)
#3 For each target language, the translation files are converted to a
(potentially not human-readable) "compiled" mapping file, which is then read
at program runtime and used for the actual translation. For the gettext po
file format, the msgfmt program can convert this to Tcl's .msg files.
If I understand correctly, your above suggestion implies that for Tcl msgcat,
the file in #2 and #3 are one and the same? In my opinion this might make
sense if and only if that file format is supported by at least as many
translation tools and offers as flexible translation updates as gettext's po
file format does. From my experience the po file format indeed offers a bunch
of features that other translation file formats are missing but which are of
significant help to the translator. That's why I would strongly suggest to do
the actual translation inside a po file, and have it converted to the msg
file afterwards.
On the other hand when I mentioned a "glossary", I was talking about a simple
text file that should collect the 15-20 most important single words from
within the project. Those words usually show up in many different translation
strings, and as a translator you would easily lose track of which word you
translated into which translation. (Example glossary terms: repository,
commit [both the verb and the noun, heh], fetch, pull, push.) That's why you
would first collect that glossary, then come up with a one-to-one translation
for each of the 20 words of the glossary, and *then* use that fixed wording
throughout all 200-500 message translations of the actual project.
Christian
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Linus Torvalds @ 2007-07-20 21:48 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200707202302.57788.johan@herland.net>
On Fri, 20 Jul 2007, Johan Herland wrote:
>
> Does this mean that you are firmly opposed to the concept of storing
> directories in the index/tree as such, or that you are only opposed to
> (some of) the implementation ideas that have been discussed so far?
I've already sent out a *patch* to do so, for chissake. It handled all
these cases perfectly fine, as far as I know, but I didn't test it all
that deeply (and made it clear when I sent that patch out).
In fact, in this whole pointless discussion, I think I'm so far the only
one to have done anything constructive at all. Sad.
So here's my standpoint:
- people who use git natively might as well use the ".gitignore" trick.
It really *does* work, and there really aren't any downsides. Those
directories will stay around forever, until you decide that you don't
want them any more. Problem solved.
Sure, if you export the git archive into some other format, you might
well want to do something about the ".gitignore" files (like just
delete them, since they won't be meaningful in an SVN environment, for
example, but you might also just convert them into SVN's "attributes"
or whatever it is that SVN uses to ignore files).
- If you don't use git natively, but just to track another thing, you
could easily use the patches that I already sent out. Yes, they need
more testing. Yes, you'd also probably like some user interface updates
(notably "git add/rm" should be taught about directories).
And yes, I probably (almost certainly) didn't handle all cases, but the
patch I sent out was actually a working one. It really *did* pass my
trivial tests.
But once you start tracking empty directories *without* a .gitignore file,
some things fall out of that:
- git really *really* is designed to track "snapshots in time". You
generate history from these snapshots. This is a very fundmanetal
issue, and a lot of people seem to have trouble understanding the
deeper implications.
For example, git and hg may look similar, but git tracks "snapshots in
time", and hg tracks "file histories tied together in snapshots". That
really is a fundamentally different thing.
And one of the fundamental results of git's approach is that content is
content. There is *never* any notion of "history". A snapshot really
is just that: it's a standalone thing. It *has* no history. The history
comes entirely from outside.
This means that the whole notion of "this directory will not go away
because I added it explicitly" is a totally broken notion in git. It
has a notion of "history" - something that simply DOES NOT EXIST,
unless you seriously break the whole notion of "snapshots in time".
In other words, when I say that git is a "content tracker", I'm
serious. It tracks nothing *but* content. If some concept doesn't exist
in the working tree, git doesn't track it. If it cannot be seen in the
filesystem, it doesn't exist.
- Contrast this with a lot of totally broken SCM's, that track "history"
of files. As a result, they have absolutely *horrid* merge problems,
because you can no longer just merge things in the working directory,
and "the result" is the result. No, if you track history, you now have
to tell the SCM about how the *history* moved, not just the content.
So this is why git MUST NOT make the difference between
- a directory was was created explicitly and then had a few files added
to it, and then had those files deleted from it
and
- we added a few files, we removed them
The end result MUST BE the same, because the state IN THE WORKING TREE is
the same!
If the contents are the same, the end result must be the same. It's that
simple. And it all comes down to: "git tracks contents".
Now, having said that, it doesn't matter *what* the end result is, as long
as it's the same for both cases. What we do now is that when the files go
away, the directory is no longer tracked.
But we *could* say that when we remove files, we always add back the
directory they were in if that directory still exists in the filesystem.
See? Both are consistent with the "git tracks contents" notion. The only
thing that is *not* consistent with that notion is to have a flag that we
carry along that says "keep this directory". That's no longer content, and
now you'd be tracking some internal SCM history instead. And that is a
mistake. It may sound like a small mistake (and it is), but down that path
lies madness. It's much better to teach people _why_ git doesn't do it,
than to say "ok, git tracks content, but we have this special case where
we also track something else, namely a git internal "stickiness" notion".
SCM is too important to play games with. Git gets things right, and I
doubt people really _realize_ that the "tracks content" is why git is so
much better, and why git can do merges so much faster and more reliably
than anybody else.
So the rule really *must* be:
- if two trees look the same in the filesystem, they *must* have the same
git SHA1, because by definition, they have the same content.
Anything that breaks that very simple statement is fundamentally broken.
Linus
PS. I realize that nobody actually seems to be writing code, and that this
is a "paint the bike shed" discussion for everybody else, but just in case
there are people who don't just masturbate about the color of the shed,
I'd like to point out that we really *do* need to enhance the "diff" rules
too, so that you can express the changes in a tree as a diff too. Because
if we track empty directories, then we need to be able to also *show* the
difference between a tree that has an empty directory, and one that does
not.
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Johan Herland @ 2007-07-20 21:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707201210550.27249@woody.linux-foundation.org>
On Friday 20 July 2007, Linus Torvalds wrote:
> [...]
>
> But that doesn't change the fundamental issue: the limitation with
> executable bits and symlinks is a limitation of the broken environment,
> not of git. But "directories stay around after the last file is gone" is
> not that, it would simply be a design mistake in git itself.
>
> There are other reasons to not do it. What about file renames? Maybe the
> directory got *renamed*. From a pure content angle, this is "all the files
> in that directory went away". If you have stupid rules like "directories
> stay around even though all the files went away", you would again have
> problems with this common case.
>
> In other words: I don't care one whit about the whiners. What's MUCH more
> important than some random whiny person saying "Daddy, daddy, I want a
> pony" is whether you can afford to maintain that pony in the future. And
> this pony is just stupid.
>
> So here:
>
> No, you cannot have a pony. NOT YOURS.
>
> but I still think we should support the concept of importing things from
> other systems, and thus eventually support empty directories. Just not any
> crazy semantics with sticky histories.
Does this mean that you are firmly opposed to the concept of storing
directories in the index/tree as such, or that you are only opposed to
(some of) the implementation ideas that have been discussed so far?
If the former is the case, does this mean that there will be no support for
empty directories in git, alternatively that such support is limited to
incorporating e.g. Dscho's .gitignore workaround into porcelain commands
(i.e. "git add --directory some_dir" will be mangled/transformed
into "touch some_dir/.gitignore && git add some_dir/.gitignore")?
(Granted, Dscho's .gitignore workaround is fairly elegant as workarounds go,
but it still reeks of inheriting a CVS misfeature.)
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Update listingblock monospace fix to support all docbook versions
From: Julian Phillips @ 2007-07-20 22:14 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Junio C Hamano, Fredrik Tolf, git
In-Reply-To: <3A4230BE-5F05-4AE9-AAB3-3B66C30DEF76@silverinsanity.com>
On Fri, 20 Jul 2007, Brian Gernhardt wrote:
>
> On Jul 20, 2007, at 8:06 AM, Julian Phillips wrote:
>
>> +while ($line = <>) {
>> + $line =~ s/^#GIT#SET#MAN#FONT#/.ft/;
>> + print $line;
>> +}
>
> Why not use `perl -pe "s/^#GIT#SET#MAN#FONT#/.ft/"` or an equivalent sed
> command in the Makefile instead of having this as a separate script?
Only because my perl foo is too weak to know the perl form, and I didn't
know how to get sed to replace unicode characters - which the original
version of the script did. I rewrote the script in my lunchbreak after I
failed to find any better way to solve the problem, and it didn't occur to
me to move it to sed at that point.
However, given the other issues with docbook xsl 1.72 I think it would
cleaner to simply say that git doesn't support 1.72. I wouldn't be
surprised if other projects weren't taking that approach.
--
Julian
---
It's computer hardware, of course it's worth having <g>
-- Espy on #Debian
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Julian Phillips @ 2007-07-20 22:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johan Herland, git
In-Reply-To: <alpine.LFD.0.999.0707201421110.27249@woody.linux-foundation.org>
On Fri, 20 Jul 2007, Linus Torvalds wrote:
>
>
> On Fri, 20 Jul 2007, Johan Herland wrote:
>>
>> Does this mean that you are firmly opposed to the concept of storing
>> directories in the index/tree as such, or that you are only opposed to
>> (some of) the implementation ideas that have been discussed so far?
>
> I've already sent out a *patch* to do so, for chissake. It handled all
> these cases perfectly fine, as far as I know, but I didn't test it all
> that deeply (and made it clear when I sent that patch out).
>
> In fact, in this whole pointless discussion, I think I'm so far the only
> one to have done anything constructive at all. Sad.
There was Dscho's .gitignore based patch too ...
>
> So here's my standpoint:
>
> - people who use git natively might as well use the ".gitignore" trick.
> It really *does* work, and there really aren't any downsides. Those
> directories will stay around forever, until you decide that you don't
> want them any more. Problem solved.
>
> Sure, if you export the git archive into some other format, you might
> well want to do something about the ".gitignore" files (like just
> delete them, since they won't be meaningful in an SVN environment, for
> example, but you might also just convert them into SVN's "attributes"
> or whatever it is that SVN uses to ignore files).
Personally I quite like this approach - I'm going to use it to keep all
the empty directories from Subversion in my importer. It seems to address
everthing quite neatly.
I don't really understand the objections ... especially since I can't see
why you want an empty directory if you're not going to put _something_ in
it - in which case, presumably you want to ignore it (so maybe a
.gitignore containing * would be better than an empty one)? However, I'm
sure that if people want it, they have a reason.
> SCM is too important to play games with. Git gets things right, and I
> doubt people really _realize_ that the "tracks content" is why git is so
> much better, and why git can do merges so much faster and more reliably
> than anybody else.
This is the thing that made me interested in git back in April '05. I
couldn't see what we were going to end up with at that point - but I was
_convinced_ that due to the underlying design it was worth watching.
Being a python type (sorry ... :$) hg looked interesting when it sprang up
- but they threw away what I considered to be one of the most compelling
features of git (at the time there wasn't the wealth of really nice tools
that we now have).
In fact, I really should say "Thank you Linus", since I came that close to
writing an SCM from scratch myself - having been using Subversion with
branches for quite some time (and CVS before that - and yes I do mean
branches + CVS). Now I no longer feel the need to write an SCM - just a
longing to use git. git is probably better than anything I would have
come up with too. :D
--
Julian
---
She is descended from a long line that her mother listened to.
-- Gypsy Rose Lee
^ 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