* Re: [PATCH] Simplified the invocation of command action in submodule
From: Imran M Yousuf @ 2008-01-09 9:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster
In-Reply-To: <47848CDD.7050806@viscovery.net>
On Jan 9, 2008 2:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> imyousuf@gmail.com schrieb:
>
> > @@ -16,6 +16,7 @@ update=
> > status=
> > quiet=
> > cached=
> > +command=
> >
> > #
> > # print stuff on stdout unless -q was specified
> > @@ -293,20 +294,23 @@ modules_list()
> > done
> > }
> >
> > +# command specifies the whole function name since
> > +# one of theirs prefix is module not modules
> > while test $# != 0
> > do
> > case "$1" in
> > add)
> > add=1
> > + command="module_$1"
> > ;;
> > init)
> > - init=1
> > + command="modules_$1"
> > ;;
> > update)
> > - update=1
> > + command="modules_$1"
> > ;;
> > status)
> > - status=1
> > + command="modules_list"
> > ;;
> > -q|--quiet)
> > quiet=1
> > @@ -320,7 +324,7 @@ do
> > branch="$2"; shift
> > ;;
> > --cached)
> > - cached=1
> > + command="modules_list"
>
> Don't remove cached=1 because otherwise --cached is effectively ignored.
>
> > ;;
> > --)
> > break
> > @@ -345,20 +349,8 @@ case "$add,$branch" in
> > ;;
> > esac
> >
> > -case "$add,$init,$update,$status,$cached" in
> > -1,,,,)
> > - module_add "$@"
> > - ;;
> > -,1,,,)
> > - modules_init "$@"
> > - ;;
> > -,,1,,)
> > - modules_update "$@"
> > - ;;
> > -,,,*,*)
> > - modules_list "$@"
> > - ;;
> > -*)
> > +if [ -z $command ]; then
> > usage
> > - ;;
> > -esac
> > +else
> > + "$command" "$@"
> > +fi
>
> - Previously 'git submodule' was equvalent to 'git submodule status', now
> it is an error.
Yes, I forgot to add that status is the default command. Thanks for
pointing it out.
>
> - Previously, passing --cached to add, init, or update was an error, now
> it is not.
The usage statement and this behaviour is rather contradicting. The
usage says that --cached can be used with all commands; so I am not
sure whether using --cached with add should be an error or not. IMHO,
if the previous implementation was right than the USAGE has to be
changed, and if the previous implementation was incorrect, than if the
default command is set to status than current implementation is right.
I would like to get comment on this until I fix the patch and resend it.
>
> -- Hannes
>
Thank you,
--
Imran M Yousuf
^ permalink raw reply
* Re: [PATCH] Simplified the invocation of command action in submodule
From: Johannes Sixt @ 2008-01-09 10:01 UTC (permalink / raw)
To: Imran M Yousuf; +Cc: git, gitster
In-Reply-To: <7bfdc29a0801090151k22d3cd5aqedb0d4860868d4d9@mail.gmail.com>
Imran M Yousuf schrieb:
> On Jan 9, 2008 2:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> - Previously, passing --cached to add, init, or update was an error, now
>> it is not.
>
> The usage statement and this behaviour is rather contradicting. The
> usage says that --cached can be used with all commands; so I am not
> sure whether using --cached with add should be an error or not. IMHO,
> if the previous implementation was right than the USAGE has to be
> changed, and if the previous implementation was incorrect, than if the
> default command is set to status than current implementation is right.
I prefer that the usage statement lists one line per sub-command with the
flags that apply only to the sub-command. IOW, a usage statement that
suggests that a flag applies to all sub-commands when in reality it
doesn't is bogus, IMHO.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Simplified the invocation of command action in submodule
From: Imran M Yousuf @ 2008-01-09 10:06 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster
In-Reply-To: <47849B60.2060000@viscovery.net>
On Jan 9, 2008 4:01 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Imran M Yousuf schrieb:
> > On Jan 9, 2008 2:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> >> - Previously, passing --cached to add, init, or update was an error, now
> >> it is not.
> >
> > The usage statement and this behaviour is rather contradicting. The
> > usage says that --cached can be used with all commands; so I am not
> > sure whether using --cached with add should be an error or not. IMHO,
> > if the previous implementation was right than the USAGE has to be
> > changed, and if the previous implementation was incorrect, than if the
> > default command is set to status than current implementation is right.
>
> I prefer that the usage statement lists one line per sub-command with the
> flags that apply only to the sub-command. IOW, a usage statement that
> suggests that a flag applies to all sub-commands when in reality it
> doesn't is bogus, IMHO.
>
I think for this patch I will keep the usage intact and keep the
implementation coherent with the current usage and add a comment in
that place so that if required it can be changed in future.
> -- Hannes
>
>
--
Imran M Yousuf
^ permalink raw reply
* Re: [PATCH] Simplified the invocation of command action in submodule
From: Lars Hjemli @ 2008-01-09 10:24 UTC (permalink / raw)
To: Imran M Yousuf; +Cc: Johannes Sixt, git, gitster
In-Reply-To: <7bfdc29a0801090151k22d3cd5aqedb0d4860868d4d9@mail.gmail.com>
On Jan 9, 2008 10:51 AM, Imran M Yousuf <imyousuf@gmail.com> wrote:
> On Jan 9, 2008 2:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> >
> > - Previously, passing --cached to add, init, or update was an error, now
> > it is not.
>
> The usage statement and this behaviour is rather contradicting. The
> usage says that --cached can be used with all commands; so I am not
> sure whether using --cached with add should be an error or not. IMHO,
> if the previous implementation was right than the USAGE has to be
> changed, and if the previous implementation was incorrect, than if the
> default command is set to status than current implementation is right.
>
> I would like to get comment on this until I fix the patch and resend it.
--cached only makes sense for the status subcommand, so the
usage/manpage probably should have looked like this (except for the
whitespace mangling...):
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cffc6d4..331e806 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,7 +10,10 @@ SYNOPSIS
--------
[verse]
'git-submodule' [--quiet] [-b branch] add <repository> [<path>]
-'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]
+'git-submodule' [--quiet] [--cached] [status] [--] [<path>...]
+'git-submodule' [--quiet] init [--] [<path>...]
+'git-submodule' [--quiet] update [--] [<path>...]
+
COMMANDS
--
1.5.3.7.1141.g4eb39
^ permalink raw reply related
* Re: [PATCH] Simplified the invocation of command action in submodule
From: Junio C Hamano @ 2008-01-09 10:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Imran M Yousuf, git
In-Reply-To: <47849B60.2060000@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Imran M Yousuf schrieb:
>> On Jan 9, 2008 2:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> - Previously, passing --cached to add, init, or update was an error, now
>>> it is not.
>>
>> The usage statement and this behaviour is rather contradicting. The
>> usage says that --cached can be used with all commands; so I am not
>> sure whether using --cached with add should be an error or not. IMHO,
>> if the previous implementation was right than the USAGE has to be
>> changed, and if the previous implementation was incorrect, than if the
>> default command is set to status than current implementation is right.
>
> I prefer that the usage statement lists one line per sub-command with the
> flags that apply only to the sub-command. IOW, a usage statement that
> suggests that a flag applies to all sub-commands when in reality it
> doesn't is bogus, IMHO.
I view the usage emitted by a command primarily as a quick
reminder for people who are _already_ familiar with the command
to help "was the option this command takes --foo or --bar? I
can never remember which X-<" situation. The usage string is
not a replacement of the manual page. For that reason, I
generally prefer short and sweet one line usage for the whole
command, even if it does not exactly capture mutually
incompatible option combinations, _as long as_ the command
itself is simple enough.
As you said, however, git-submodule is a command dispatcher on
its own, and what its subcommands do are quite different, to the
point that they probably should not even be sharing the option
parser. One line per subcommand feels more appropriate.
By the way, Imran, if the current implementation declares a
combination of "add" and "--cached" an error, and a new
implementation does not, that's called a regression. Unless you
can prove that the combination makes sense and the existing
behaviour is a bug, in which case you can say the new
implementation fixes the bug.
In this case, module_add does not even pay attention to $cached
in the existing code. The choice is between (1) silently ignore
user's expectation that "add --cached" would do something
different from "add" without "--cached", or (2) tell the user
that the combination does not make sense and error out. To
people who _know_ what the command does, the choice between the
two does not make much difference (they do not give ignored
option, nor trigger the error), but to new people the latter is
often easier to use.
^ permalink raw reply
* Re: [PATCH] - Added recurse command to git submodule
From: Lars Hjemli @ 2008-01-09 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: imyousuf, git, Imran M Yousuf
In-Reply-To: <7vmyrfjsw1.fsf@gitster.siamese.dyndns.org>
On Jan 9, 2008 9:38 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I am not still convinced that a subcommand other than init,
> which is started recursively, should initialize and update
> submodules that are uninitialized.
I very much agree; this behaviour would break the current 'usage model'.
> I suspect that it might be a saner approach to:
>
> - allow "git submodule recurse init [-d depth]" (although I am
> not sure if limit by depth is so useful in practice -- only
> experience will tell us) to auto-initialize the uninitialized
> submodules;
A possible extension is to specifiy "inter-submodule" paths to the
init subcommand, i.e. for a possible KDE layout:
git submodule -r init kdelibs kdelibs/admin
This should then recursively initialize the kdelibs submodule and the
admin-submodule (in the kdelibs submodule).
Btw: from my reading of the code, the git-command specified for
'recurse' will be done top-to-bottom: I guess that's what you want for
something like 'git submodule recurse diff', but not for something
like 'git submodule recurse commit' (but IMHO the latter one should
never be executed ;-)
--
larsh
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-09 10:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, J. Bruce Fields, Steffen Prohaska,
Robin Rosenberg, Jeff King, Peter Karlsson, Git Mailing List,
msysGit
In-Reply-To: <7vd4sbmnmz.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
Hi,
On Wed, 9 Jan 2008, Junio C Hamano wrote:
> Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> writes:
>
> > On Tue, 8 Jan 2008, Junio C Hamano wrote:
> >>
> >> I think the project can mark text files as text with attributes and
> >> if the port to the platform initialized core.autocrlf appropriately
> >> for the platform everything should work as you described.
> >
> > Yes, I think core.autocrlf should default to "true" on Windows, since
> > that is what it's about. The alternative is to have "fail"/"warn", to
> > just make sure that nobody can do the wrong thing by mistake.
> >
> > We could just do something like this, although that probably does mean
> > that the whole test-suite needs to be double-checked (ie now we really
> > do behave differently on windows outside of any config options!))
> >
> > People who really dislike it can always do the
> >
> > git config --global core.autocrlf false
> >
> > thing.
> >
> > (And no, I don't know if "#ifdef __WINDOWS__" is the right thing to
> > do, it's almost certainly not. This is just a draft.)
IMHO this is really not good. Better do it in the global /etc/gitconfig
we install _anyway_ (it says core.symlinks=false).
> Perhaps we can do something similar to core.filemode? Create a file
> that we would need to create anyway in "text" mode, and read it back in
> "binary" mode to see what stdio did?
The problem is that MinGW behaves sanely, i.e. it does not output CRLF but
only LF.
Besides, as I stated several times already, there _are_ projects on
Windows where you do _not_ want crlf=true:
- Windows is already slow. So slow that it is not even funny. Granted,
if you use Windows daily, git on MinGW seems snappy, but if you come
from Linux, it is slow as hell.
And CRLF conversion does not help that impression at all.
- Some tools ported to Windows from Unix do not like CRs.
- For git itself, I prefer to work without CRLF just because I do not need
it.
But maybe I am the minority here, and we really should default to
crlf=true on Windows, and provide a way to unset that.
My preference would be to have Peff's -c switch to clone, but
_additionally_ a way to force a full re-checkout of files (for example
after "git config core.crlf false").
Ciao,
Dscho
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-09 10:56 UTC (permalink / raw)
To: Peter Karlsson
Cc: Git Mailing List, Robin Rosenberg, Jeff King, Steffen Prohaska,
Linus Torvalds
In-Reply-To: <alpine.DEB.1.00.0801082226110.21686@perkele.intern.softwolves.pp.se>
Hi,
On Tue, 8 Jan 2008, Peter Karlsson wrote:
> Linus Torvalds:
>
> > So defaulting to (or asking) "autocrlf" at install time is probably
> > the safest thing, and then people can edit their global .gitconfig to
> > turn it off.
>
> Indeed. A checkbox in the Windows installer (like Cygwin has) would be
> nice.
No. There are different needs for different projects, and having
different defaults just adds to the confusion.
I am no longer opposed to setting crlf=true by default for Git (although
this does not necessarily hold true for msysGit, but that could be
helped by explicitely unsetting crlf for the repositories we check out
with the netinstaller).
Ciao,
Dscho
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-09 11:03 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, J. Bruce Fields, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List, msysGit
In-Reply-To: <B655B6FF-9377-434A-A979-2E758771B0FA-wjoc1KHpMeg@public.gmane.org>
Hi,
On Tue, 8 Jan 2008, Steffen Prohaska wrote:
> On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:
>
> > I think the project can mark text files as text with attributes and if
> > the port to the platform initialized core.autocrlf appropriately for
> > the platform everything should work as you described.
> >
> > At least that is how I read the description of `crlf` in
> > gitattributes(5).
>
> But we do not want to mark a file as text but tell git to run its
> auto-detection and use the local default line endings. But for
> different projects we do not even want to run the auto-detection, but
> leave the files as is.
Probably the best thing would be to default to crlf=true, and then have a
.gitattributes file like this in your project:
-- snip --
*.am -crlf
-- snap --
(Did I guess right about the file extension? But why do you want to check
in huge 3D stacks? Ah, of course, for test cases.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] additional help when editing during interactive rebase
From: Johannes Schindelin @ 2008-01-09 11:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, William Morgan
In-Reply-To: <7vsl17pv1c.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 8 Jan 2008, Junio C Hamano wrote:
> I would have removed those empty lines around the instruction if I were
> patching this, though. Losing 5 lines out of 25-line terminal was
> marginally Ok. Losing 9 lines 4 lines too many and is unacceptable.
>
> Thoughts?
I wonder if it would not make even more sense to record the current HEAD
name, and call "commit --amend" if it is the same upon "--continue".
Note that "commit --amend" is _already_ called automatically if the index
is dirty (but agrees with the working directory).
Then the user would be spared some additional typing, and the help could
be changed to hint at "rebase --continue". It also would make things more
consistent.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] shortlog: mention the "-e" option in the usage
From: Johannes Schindelin @ 2008-01-09 11:39 UTC (permalink / raw)
To: git, gitster
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-shortlog.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 3d8d709..fa8bc7d 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -8,7 +8,7 @@
#include "mailmap.h"
static const char shortlog_usage[] =
-"git-shortlog [-n] [-s] [<commit-id>... ]";
+"git-shortlog [-n] [-s] [-e] [<commit-id>... ]";
static char *common_repo_prefix;
static int email;
--
1.5.4.rc2.72.g74f4d
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-09 12:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Peter Karlsson, Git Mailing List, Robin Rosenberg, Jeff King,
Linus Torvalds
In-Reply-To: <alpine.LSU.1.00.0801091054400.31053@racer.site>
On Jan 9, 2008, at 11:56 AM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 8 Jan 2008, Peter Karlsson wrote:
>
>> Linus Torvalds:
>>
>>> So defaulting to (or asking) "autocrlf" at install time is probably
>>> the safest thing, and then people can edit their
>>> global .gitconfig to
>>> turn it off.
>>
>> Indeed. A checkbox in the Windows installer (like Cygwin has)
>> would be
>> nice.
>
> No. There are different needs for different projects, and having
> different defaults just adds to the confusion.
>
> I am no longer opposed to setting crlf=true by default for Git
> (although
> this does not necessarily hold true for msysGit, but that could be
> helped by explicitely unsetting crlf for the repositories we check out
> with the netinstaller).
I'll further think about "crlf=safe" (see another mail in this
thread). I like the idea of safe because it guarantees that data
will never be corrupted. But I have no time to think about it
immediately.
Steffen
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-09 12:45 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, J. Bruce Fields, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List, msysGit
In-Reply-To: <alpine.LSU.1.00.0801091100401.31053-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org>
On Jan 9, 2008, at 12:03 PM, Johannes Schindelin wrote:
> On Tue, 8 Jan 2008, Steffen Prohaska wrote:
>
>> On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:
>>
>>> I think the project can mark text files as text with attributes
>>> and if
>>> the port to the platform initialized core.autocrlf appropriately for
>>> the platform everything should work as you described.
>>>
>>> At least that is how I read the description of `crlf` in
>>> gitattributes(5).
>>
>> But we do not want to mark a file as text but tell git to run its
>> auto-detection and use the local default line endings. But for
>> different projects we do not even want to run the auto-detection, but
>> leave the files as is.
>
> Probably the best thing would be to default to crlf=true, and then
> have a
> .gitattributes file like this in your project:
>
> -- snip --
> *.am -crlf
> -- snap --
>
> (Did I guess right about the file extension? But why do you want to
> check
> in huge 3D stacks? Ah, of course, for test cases.)
Yes, thanks ;)
For now, this is the right thing to do. However, our file format
and the application does not depend on the extension. A a long
term solution, I'll fix our file format header to include '\0' if
the file is binary.
Steffen
^ permalink raw reply
* Re: git svn fetch segfaults
From: Dennis Schridde @ 2008-01-09 12:53 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080109003307.GS29972@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
Am Mittwoch, 9. Januar 2008 01:33:07 schrieb Miklos Vajna:
> On Tue, Jan 08, 2008 at 11:25:45PM +0100, Dennis Schridde
<devurandom@gmx.net> wrote:
> > mkdir org.gna.warzone2100.git
> > cd org.gna.warzone2100.git
> > git --bare init
> > git --bare svn init --use-svnsync-props --stdlayout
> > file:///var/svn/warzone2100/
> > git --bare svn fetch
>
> wget http://svn.kynes.de/warzone2100.bz2
>
> svnadmin create warzone2100 && bzcat warzone2100.bz2 | svnadmin load
> warzone2100
>
> the rest is the same i get a segfault at the very same place.
>
> > If I do not specify --use-svnsync-prop to "git svn init", it gets past
> > r13 in tags/1.10a.
>
> same.
>
> > I am using these versions:
> > svn, version 1.4.6 (r28521)
> > git version 1.5.4.rc2
>
> $ svn --version
> svn, version 1.4.5 (r25188)
>
> $ git --version
> git version 1.5.4.rc2.38.gd6da3
Same with git version 1.5.3.7
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Fix the MacOS X compile of gitk by pinching po2msg.sh from git-gui
From: Charles Bailey @ 2008-01-09 13:29 UTC (permalink / raw)
To: git
Make the behaviour of a top level make NO_MSGFMT=Yes consistent when
performing the subdirectory builds in gitk-git and git-gui.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
gitk-git/Makefile | 7 ++++++-
{git-gui => gitk-git}/po/.gitignore | 0
{git-gui => gitk-git}/po/po2msg.sh | 0
3 files changed, 6 insertions(+), 1 deletions(-)
copy {git-gui => gitk-git}/po/.gitignore (100%)
copy {git-gui => gitk-git}/po/po2msg.sh (100%)
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index 6158504..ae2b80b 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -18,7 +18,12 @@ TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
## po-file creation rules
XGETTEXT ?= xgettext
-MSGFMT ?= msgfmt
+ifdef NO_MSGFMT
+ MSGFMT ?= $(TCL_PATH) po/po2msg.sh
+else
+ MSGFMT ?= msgfmt
+endif
+
PO_TEMPLATE = po/gitk.pot
ALL_POFILES = $(wildcard po/*.po)
ALL_MSGFILES = $(subst .po,.msg,$(ALL_POFILES))
diff --git a/git-gui/po/.gitignore b/gitk-git/po/.gitignore
similarity index 100%
copy from git-gui/po/.gitignore
copy to gitk-git/po/.gitignore
diff --git a/git-gui/po/po2msg.sh b/gitk-git/po/po2msg.sh
similarity index 100%
copy from git-gui/po/po2msg.sh
copy to gitk-git/po/po2msg.sh
--
1.5.4.rc2.60.gb2e62
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-09 13:32 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, J. Bruce Fields, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List, msysGit
In-Reply-To: <019B1C82-27BF-4B6B-981D-5498D31B5DD3-wjoc1KHpMeg@public.gmane.org>
Hi,
On Wed, 9 Jan 2008, Steffen Prohaska wrote:
> On Jan 9, 2008, at 12:03 PM, Johannes Schindelin wrote:
>
> > -- snip --
> > *.am -crlf
> > -- snap --
> >
> > (Did I guess right about the file extension? But why do you want to
> > check in huge 3D stacks? Ah, of course, for test cases.)
>
> Yes, thanks ;)
>
> For now, this is the right thing to do. However, our file format and
> the application does not depend on the extension. A a long term
> solution, I'll fix our file format header to include '\0' if the file is
> binary.
Of course, that would help the binary detection of both subversion and
git, but it would break 3rd party readers of the format :-(
Thanks for the heads-up,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix the MacOS X compile of gitk by pinching po2msg.sh from git-gui
From: Johannes Schindelin @ 2008-01-09 13:40 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20080109132953.GA12489@hashpling.org>
Hi,
On Wed, 9 Jan 2008, Charles Bailey wrote:
> Make the behaviour of a top level make NO_MSGFMT=Yes consistent when
> performing the subdirectory builds in gitk-git and git-gui.
>
> Signed-off-by: Charles Bailey <charles@hashpling.org>
> ---
> gitk-git/Makefile | 7 ++++++-
> {git-gui => gitk-git}/po/.gitignore | 0
> {git-gui => gitk-git}/po/po2msg.sh | 0
> 3 files changed, 6 insertions(+), 1 deletions(-)
> copy {git-gui => gitk-git}/po/.gitignore (100%)
> copy {git-gui => gitk-git}/po/po2msg.sh (100%)
Since gitk and git-gui are separate projects (pulled at irregular
intervals into git.git), your patch looks sane, but would be better done
as a patch against gitk.git.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix the MacOS X compile of gitk by pinching po2msg.sh from git-gui
From: Charles Bailey @ 2008-01-09 13:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.LSU.1.00.0801091339390.31053@racer.site>
On Wed, Jan 09, 2008 at 01:40:46PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 9 Jan 2008, Charles Bailey wrote:
>
> > --- snip ---
>
> Since gitk and git-gui are separate projects (pulled at irregular
> intervals into git.git), your patch looks sane, but would be better done
> as a patch against gitk.git.
>
> Ciao,
> Dscho
I'm sorry, I think I knew this once, but had forgotten. Of course, as
a patch against gitk, I think it gets quite verbose as the patch
includes a full copy of the po2msg.sh script.
Is there a simple way to generate a gitk.git patch from a git.git
clone, or do I need to clone a gitk repository from somewhere?
Perhaps I could just flag this as a reasonably important MacOS X
1.5.4-rc issue until I can sort out a more suitable patch?
Thanks,
Charles.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Gregory Jefferis @ 2008-01-09 13:52 UTC (permalink / raw)
To: Steffen Prohaska, Johannes Schindelin
Cc: Peter Karlsson, Git Mailing List, Robin Rosenberg, Jeff King,
Linus Torvalds
In-Reply-To: <04EF2652-9AA8-4976-903F-DBE4E7AA13D7@zib.de>
On 9/1/08 12:41, "Steffen Prohaska" <prohaska@zib.de> wrote:
> I'll further think about "crlf=safe" (see another mail in this
> thread). I like the idea of safe because it guarantees that data
> will never be corrupted. But I have no time to think about it
> immediately.
crlf=safe [i.e. munging CRLFs only if there are no bare LFs] sounds
appealing to me as well because it looks like munging that is always
reversible. However there could still be problems at checkout. To be
really safe, it seems to me that it must be 1) reversible in practice and 2)
ALWAYS reversed unless we explicitly ask for no gnuming at checkout. Why?
Re point (1) to be reversible in practice, we need to know who we've munged.
Otherwise when gnuming blindly at checkout we might damage some innocent
bystander file that only ever had LFs in the first place. So it seems we
would have to keep track of who was munged. But do we want to store this in
the repository?
Re (2) well if we happen to munge a file on checkin that is actually binary,
it must be gnumed on the way out otherwise it will be broken for the user.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-09 14:03 UTC (permalink / raw)
To: Gregory Jefferis
Cc: Steffen Prohaska, Peter Karlsson, Git Mailing List,
Robin Rosenberg, Jeff King, Linus Torvalds
In-Reply-To: <C3AA823B.10C50%jefferis@gmail.com>
Hi,
On Wed, 9 Jan 2008, Gregory Jefferis wrote:
> On 9/1/08 12:41, "Steffen Prohaska" <prohaska@zib.de> wrote:
>
> > I'll further think about "crlf=safe" (see another mail in this
> > thread). I like the idea of safe because it guarantees that data will
> > never be corrupted. But I have no time to think about it immediately.
>
> crlf=safe [i.e. munging CRLFs only if there are no bare LFs] sounds
> appealing to me as well because it looks like munging that is always
> reversible.
There is a bigger problem here, though: As of now, you can add a (loose)
object from a big file pretty easily even on a small machine, because you
do not need the whole buffer, but you stream it to hash-object. IIRC
Junio wrote a patch to allow this with "git-add", using fast-import, but
that patch probably hasn't been applied.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix the MacOS X compile of gitk by pinching po2msg.sh from git-gui
From: Johannes Schindelin @ 2008-01-09 14:06 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20080109135249.GA12869@hashpling.org>
Hi,
On Wed, 9 Jan 2008, Charles Bailey wrote:
> On Wed, Jan 09, 2008 at 01:40:46PM +0000, Johannes Schindelin wrote:
>
> > On Wed, 9 Jan 2008, Charles Bailey wrote:
> >
> > > --- snip ---
> >
> > Since gitk and git-gui are separate projects (pulled at irregular
> > intervals into git.git), your patch looks sane, but would be better
> > done as a patch against gitk.git.
>
> I'm sorry, I think I knew this once, but had forgotten.
Oh, my critique was not meant as harsh as it was apparently received: for
reviewing purposes, your way was perfect, as it shows your intent better
than the technically correct patch.
All I'm saying is that you should send the (verbose) patch, too, possibly
referring to the smaller patch in the space between the three dashes and
the diffstat.
(I would also prefix this patch with "gitk:", instead of writing "of
gitk", so that people reading the log of git.git get a better idea what
this is about.)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] gitk: Fix the Makefile to cope with systems lacking msgfmt
From: Charles Bailey @ 2008-01-09 14:31 UTC (permalink / raw)
To: git
The po2msg.sh script and the .gitignore in the po directory have been
shamelessly copied from the current git-gui. This enables the top
level "make NO_MSGFMT" to work consistently for git across the git-gui
and gitk sub-projects.
This is the same effective patch that has previously been posted as a
git.git patch which more succinctly described the copying of
po/.gitignore and po/po2msg.sh from git-gui.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
Makefile | 7 +++-
po/.gitignore | 2 +
po/po2msg.sh | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 141 insertions(+), 1 deletions(-)
create mode 100644 po/.gitignore
create mode 100644 po/po2msg.sh
diff --git a/Makefile b/Makefile
index 6158504..ae2b80b 100644
--- a/Makefile
+++ b/Makefile
@@ -18,7 +18,12 @@ TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
## po-file creation rules
XGETTEXT ?= xgettext
-MSGFMT ?= msgfmt
+ifdef NO_MSGFMT
+ MSGFMT ?= $(TCL_PATH) po/po2msg.sh
+else
+ MSGFMT ?= msgfmt
+endif
+
PO_TEMPLATE = po/gitk.pot
ALL_POFILES = $(wildcard po/*.po)
ALL_MSGFILES = $(subst .po,.msg,$(ALL_POFILES))
diff --git a/po/.gitignore b/po/.gitignore
new file mode 100644
index 0000000..a89cf44
--- /dev/null
+++ b/po/.gitignore
@@ -0,0 +1,2 @@
+*.msg
+*~
diff --git a/po/po2msg.sh b/po/po2msg.sh
new file mode 100644
index 0000000..c63248e
--- /dev/null
+++ b/po/po2msg.sh
@@ -0,0 +1,133 @@
+#!/bin/sh
+# Tcl ignores the next line -*- tcl -*- \
+exec tclsh "$0" -- "$@"
+
+# This is a really stupid program, which serves as an alternative to
+# msgfmt. It _only_ translates to Tcl mode, does _not_ validate the
+# input, and does _not_ output any statistics.
+
+proc u2a {s} {
+ set res ""
+ foreach i [split $s ""] {
+ scan $i %c c
+ if {$c<128} {
+ # escape '[', '\' and ']'
+ if {$c == 0x5b || $c == 0x5d} {
+ append res "\\"
+ }
+ append res $i
+ } else {
+ append res \\u[format %04.4x $c]
+ }
+ }
+ return $res
+}
+
+set output_directory "."
+set lang "dummy"
+set files [list]
+set show_statistics 0
+
+# parse options
+for {set i 0} {$i < $argc} {incr i} {
+ set arg [lindex $argv $i]
+ if {$arg == "--statistics"} {
+ incr show_statistics
+ continue
+ }
+ if {$arg == "--tcl"} {
+ # we know
+ continue
+ }
+ if {$arg == "-l"} {
+ incr i
+ set lang [lindex $argv $i]
+ continue
+ }
+ if {$arg == "-d"} {
+ incr i
+ set tmp [lindex $argv $i]
+ regsub "\[^/\]$" $tmp "&/" output_directory
+ continue
+ }
+ lappend files $arg
+}
+
+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
+ }
+
+ if {$msgid == ""} {
+ 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"]
+ fconfigure $in -encoding utf-8
+ set out [open $outfile "w"]
+
+ set mode ""
+ while {[gets $in line] >= 0} {
+ if {[regexp "^#" $line]} {
+ if {[regexp ", fuzzy" $line]} {
+ set fuzzy 1
+ } else {
+ flush_msg
+ }
+ continue
+ } elseif {[regexp "^msgid \"(.*)\"$" $line dummy match]} {
+ flush_msg
+ set msgid $match
+ set mode "msgid"
+ } elseif {[regexp "^msgstr \"(.*)\"$" $line dummy match]} {
+ set msgstr $match
+ set mode "msgstr"
+ } elseif {$line == ""} {
+ flush_msg
+ } elseif {[regexp "^\"(.*)\"$" $line dummy match]} {
+ if {$mode == "msgid"} {
+ append msgid $match
+ } elseif {$mode == "msgstr"} {
+ append msgstr $match
+ } else {
+ puts stderr "I do not know what to do: $match"
+ }
+ } else {
+ puts stderr "Cannot handle $line"
+ }
+ }
+ flush_msg
+ close $in
+ close $out
+}
+
+if {$show_statistics} {
+ puts [concat "$translated_count translated messages, " \
+ "$fuzzy_count fuzzy ones, " \
+ "$not_translated_count untranslated ones."]
+}
--
1.5.4.rc2.60.gb2e62
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Dmitry Potapov @ 2008-01-09 15:03 UTC (permalink / raw)
To: Gregory Jefferis
Cc: Steffen Prohaska, Johannes Schindelin, Peter Karlsson,
Git Mailing List, Robin Rosenberg, Jeff King, Linus Torvalds
In-Reply-To: <C3AA823B.10C50%jefferis@gmail.com>
On Wed, Jan 09, 2008 at 01:52:59PM +0000, Gregory Jefferis wrote:
>
> crlf=safe [i.e. munging CRLFs only if there are no bare LFs] sounds
> appealing to me as well because it looks like munging that is always
> reversible. However there could still be problems at checkout. To be
> really safe, it seems to me that it must be 1) reversible in practice and 2)
> ALWAYS reversed unless we explicitly ask for no gnuming at checkout. Why?
>
> Re point (1) to be reversible in practice, we need to know who we've munged.
> Otherwise when gnuming blindly at checkout we might damage some innocent
> bystander file that only ever had LFs in the first place.
If you work on Windows and you have clrf=safe, you cannot put a text
file that has only LFs, because naked LF is not allowed. If you want
to have naked LF in some file, you have to say that explicitly in
.gitattributes.
If you work on cross platform project, and somebody else put a file with
bare LFs, which is not text though heauristic wrongly detected it as
text then you can remove this file from your working directory, correct
.gitattributes and checkout this file again. The idea of crlf=safe is
that information is never lost. It is always fully reversible, and if
you put something into the repostory, you always get back exactly the
same unless you changed your .gitattributes.
> Re (2) well if we happen to munge a file on checkin that is actually binary,
> it must be gnumed on the way out otherwise it will be broken for the user.
Of course, it will, because the same heuristic will detect it as text,
and convert it back. So as long as you stay on the same platform and
with the same .gitattributes, you always get back exactly what you
put.
Dmitry
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Dmitry Potapov @ 2008-01-09 15:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Gregory Jefferis, Steffen Prohaska, Peter Karlsson,
Git Mailing List, Robin Rosenberg, Jeff King, Linus Torvalds
In-Reply-To: <alpine.LSU.1.00.0801091401101.31053@racer.site>
On Wed, Jan 09, 2008 at 02:03:32PM +0000, Johannes Schindelin wrote:
>
> On Wed, 9 Jan 2008, Gregory Jefferis wrote:
>
> > crlf=safe [i.e. munging CRLFs only if there are no bare LFs] sounds
> > appealing to me as well because it looks like munging that is always
> > reversible.
>
> There is a bigger problem here, though: As of now, you can add a (loose)
> object from a big file pretty easily even on a small machine, because you
> do not need the whole buffer, but you stream it to hash-object. IIRC
> Junio wrote a patch to allow this with "git-add", using fast-import, but
> that patch probably hasn't been applied.
I don't think that crlf=safe requires that the whole file was put into
the buffer. It can work with stream, but it will call die() if a file
that was detected as text has a naked LF.
Dmitry
^ permalink raw reply
* [RFC] refer to post-patch lines in whitespace warnings
From: Daniel Barkalow @ 2008-01-09 15:57 UTC (permalink / raw)
To: git
When I rebase series with bad whitespace, I end up with unhelpful messages
like:
.dotest/patch:412: trailing whitespace.
--
.dotest/patch:446: trailing whitespace.
--
These line numbers obviously refer to lines in a file that's been removed
by the time I can do anything about it. It seems to me like the message
would be more useful if, in the case where it leaves the working tree
modified with the non-compliant whitespace, it gave this location rather
than the patch's location (because, even if you have the patch still,
you'd need to revert it first in order to be able to apply a fixed version
anyway). Anybody see any problems with this theory?
-Daniel
*This .sig left intentionally blank*
^ 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