* Re: [PATCH 3/6] stg mail: make __send_message do more
From: Karl Wiberg @ 2009-12-01 7:26 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091130235935.GK12733@ldl.fc.hp.com>
On Tue, Dec 1, 2009 at 12:59 AM, Alex Chiang <achiang@hp.com> wrote:
> * Karl Wiberg <kha@treskal.com>:
>
> > You could consolidate the two dictionaries like this, to avoid
> > making the same choice twice and make the code more pleasant to
> > read:
> >
> > (build, outstr) = { 1: (__build_cover, 'the cover message'), 4: (__build_message, 'patch "%s"' % args[0]) }
>
> Hm, I don't think that's valid. I ended up doing something like
> this:
>
> d = { 'cover': (__build_cover, 'the cover message'), 'patch': (__build_message, 'patch "%s"' % args[0]) }
> (build, outstr) = d[type]
Duh. That's what I get for posting untested code. It should be
(build, outstr) = { 1: (__build_cover, 'the cover message'), 4:
(__build_message, 'patch "%s"' % args[0]) }[len(args)]
That is, we create a dictionary only to immediately use it once,
without ever explicitly storing a reference to it.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 5/6] stg mail: add basic support for git send-email
From: Karl Wiberg @ 2009-12-01 7:33 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091201000048.GL12733@ldl.fc.hp.com>
On Tue, Dec 1, 2009 at 1:00 AM, Alex Chiang <achiang@hp.com> wrote:
> * Karl Wiberg <kha@treskal.com>:
>
> > try:
> > try:
> > cmd.append(path)
> > call(cmd)
> > except Exception, e:
> > raise CmdException(str(e))
> > finally:
> > os.unlink(path)
> >
> > (The combined try...except...finally statement didn't appear until
> > python 2.5, but we'd like to stay compatible with 2.4.)
>
> This statement confuses me a bit. The way I read it, I shouldn't use
> your suggestion due to compat reasons?
Oh. No, the "combined" statement would look like this:
try:
cmd.append(path)
call(cmd)
except Exception, e:
raise CmdException(str(e))
finally:
os.unlink(path)
It works exactly like the nested try...finally and try...except
statement above, but results in less indentation---and would thus be
preferred, if not for the 2.4 compatibility issue.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Junio C Hamano @ 2009-12-01 7:34 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, Johannes Schindelin, Jay Soffian, git
In-Reply-To: <36ca99e90911302249r5f77f031o73cc7bb13dc375cf@mail.gmail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> On Tue, Dec 1, 2009 at 01:21, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Hmm, the Subject: matches what the code does, but nobody mentions why it
>> is necessary (iow, what breaks in the current code and what becomes better
>> if the patch is applied). The blank space before your "S-o-b:" line is
>> for you to describe these things.
> Sure. unfortunately the code where the string list is filled is not in
> the patch. But if you look at the code it should be self-explanatory.
That is _exactly_ why I want the description in the commit log message. I
don't want commit messages (or lack thereof) to force people to look at
the code outside the patch.
Otherwise I'll have to ask _you_ to personally give the 7-line explanation
you just gave us to anybody who runs "git log -p" with the default context
size after this patch is applied. I do not think you have the bandwidth
to handle that ;-).
> There is actually also an other solution: we could first strdup the
> ref name to the .util member and take this as the input for the
> abbrev_ref()/string list entry and safe there the strdup.
I too thought something like that may make sense, but it doesn't look like
so, for two reasons:
- string-list API is a bit cumbersome to use if you allocate the string
yourself. You will be made responsible for freeing them, and often you
do so by setting strdup_strings to true immediately before calling
string_list_clear(), which is kind of ugly;
- The ref abbrev_branch() is called and the address of whose substring is
taken to be used as "name" in handle_one_branch() is refspec.src, but
what goes to .util is refname that is refspec.dst---they are different
strings and one is not a substring of the other.
IOW, your patch text is good; it just would have been better with a bit
more explanation.
Thanks, will queue in 'maint'.
^ permalink raw reply
* Re: [PATCH v2 4/6] build dashless "bin-wrappers" directory similar to installed bindir
From: Matthew Ogilvie @ 2009-12-01 7:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmy241q75.fsf@alter.siamese.dyndns.org>
On Sun, Nov 29, 2009 at 10:28:46PM -0800, Junio C Hamano wrote:
> Matthew Ogilvie <mmogilvi_git@miniinfo.net> writes:
> > +GIT_EXEC_PATH="__GIT_EXEC_PATH__"
> > +exec "${GIT_EXEC_PATH}/__PROG__" "$@"
>
> Two issues, one minor and one not so minor but not grave:
>
> - Everywhere else we seem to use "@@UPPERCASE_NAME@@" not
> double-underscore as placeholders like the above.
>
> - @@PROG@@ is under our control and it is easy for us to guarantee that
> it won't have any funny letters, but GIT_EXEC_PATH is not. Is it safe
> to do a simple-minded "sed" replacement, or does it need the usual sq
> trick employed in the other replacement in our Makefile?
You've already applied the v2 patch to pu, but if it is still
a concern, you might either add or squash in the patch at
the bottom of this message for the @@ vs __ issue. But first,
some thoughts about escaping $(shell pwd):
-------------
The patch below also switches to using single quotes in the wrapper
script, but that by itself doesn't fix everything. Basically it
fixes '"', '$', (and maybe/partially '\\') at the expense of
breaking '\''. Several characters are still
broken: '\'', '|', '&', '\\', and maybe others. Either option
should handle ' ' (space) OK.
The "standard" *_SQ replacement used elsewhere in the makefile
is inadequate in this context, since we really needs to escape
makefile, shell, sed, and then shell again. It might be possible
to define something like the following, and then use it instead
of $(shell pwd). You could also try several nested
$(subst ...)'s instead of sed. I have not tried either of these.
build_dir_MQ=$(shell pwd | sed -e "s/'/'\"'\"'/g" \
-e 's/[|&\\]/\\&/g' \
-e "s/'/'\"'\"'/g" )
Rationale:
Working backwards, the last -e makes sure the sed argument doesn't
get split or combined by the shell before it gets to sed. The
middle -e is intended to escape characters that sed would
misinterpret. The first -e is so that single quotes get
properly interpreted by the shell that interprets
bin-wrappers/* generated scripts.
But I don't really think this is worth it:
1. I think there are parts of test-lib.sh (and maybe other places)
that don't even handle spaces in top-level $(pwd), let alone more
complicated characters. (git itself should be robust, though)
2. Technically, stuff like SHELL_PATH_SQ (anything that is used
by the makefile as the replacement text for a sed 's' command) may
benefit from something similar. (But other uses like -DVAR='$(xx_SQ)'
are probably perfect already.)
3. It doesn't seem like a severe restriction to require that users
build git in a directory with a reasonably normal full path name.
-------------
From: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Date: Mon, 30 Nov 2009 22:57:40 -0700
Subject: [PATCH] wrap-for-bin.sh: Use @@var@@ for Makefile variable expansion
We use @@var@@-style variable expansion in most other places, so be
consistent with them.
Also, rename it to @@BUILD_DIR@@ to clarify what it is expanded with,
and use single quotes in wrap-for-bin.sh to reduce the number of shell
meta characters that might mess it up.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Makefile | 4 ++--
wrap-for-bin.sh | 12 ++++++------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index c8f0c5f..811db45 100644
--- a/Makefile
+++ b/Makefile
@@ -1791,8 +1791,8 @@ all:: $(TEST_PROGRAMS) $(test_bindir_programs)
bin-wrappers/%: wrap-for-bin.sh
@mkdir -p bin-wrappers
$(QUIET_GEN)sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
- -e 's|__GIT_EXEC_PATH__|$(shell pwd)|' \
- -e 's|__PROG__|$(@F)|' < $< > $@ && \
+ -e 's|@@BUILD_DIR@@|$(shell pwd)|' \
+ -e 's|@@PROG@@|$(@F)|' < $< > $@ && \
chmod +x $@
# GNU make supports exporting all variables by "export" without parameters.
diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh
index ee2bc98..c5075c9 100644
--- a/wrap-for-bin.sh
+++ b/wrap-for-bin.sh
@@ -4,12 +4,12 @@
# to run test suite against sandbox, but with only bindir-installed
# executables in PATH. The Makefile copies this into various
# files in bin-wrappers, substituting
-# __GIT_EXEC_PATH__ and __PROG__.
+# @@BUILD_DIR@@ and @@PROG@@.
-GIT_EXEC_PATH="__GIT_EXEC_PATH__"
-GIT_TEMPLATE_DIR="__GIT_EXEC_PATH__/templates/blt"
-GITPERLLIB="__GIT_EXEC_PATH__/perl/blib/lib"
-PATH="__GIT_EXEC_PATH__/bin-wrappers:$PATH"
+GIT_EXEC_PATH='@@BUILD_DIR@@'
+GIT_TEMPLATE_DIR='@@BUILD_DIR@@/templates/blt'
+GITPERLLIB='@@BUILD_DIR@@/perl/blib/lib'
+PATH='@@BUILD_DIR@@/bin-wrappers:'"$PATH"
export GIT_EXEC_PATH GIT_TEMPLATE_DIR GITPERLLIB PATH
-exec "${GIT_EXEC_PATH}/__PROG__" "$@"
+exec "${GIT_EXEC_PATH}/@@PROG@@" "$@"
--
1.6.4.GIT
^ permalink raw reply related
* Re: [StGit RFC PATCH 0/6] add support for git send-email
From: Karl Wiberg @ 2009-12-01 7:38 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091201000258.GM12733@ldl.fc.hp.com>
On Tue, Dec 1, 2009 at 1:02 AM, Alex Chiang <achiang@hp.com> wrote:
> * Karl Wiberg <kha@treskal.com>:
>
>> Did you remember to run the regression tests? It's very helpful when
>> reviewing to know that the regression suite passes at every point in
>> the series.
>
> Good idea. I've been running t/t1900-mail.sh at each stage
Perfect.
> since my changes seem rather localized to sending mail.
>
> Should I be running the entire suite?
Just running that single test should be sufficient in this case; as
you say, the changes are rather well contained.
Running the whole suite takes a few minutes, so it might be worth
doing once in a while.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Thomas Singer @ 2009-12-01 7:49 UTC (permalink / raw)
To: git
In-Reply-To: <4B123C80.30607@syntevo.com>
Thomas Singer wrote:
> Reece Dunn wrote:
>> This is a bug in git's character encoding/conversion logic. It looks
>> like git is taking the source string and converting it to ascii to be
>> displayed on the console output (e.g. by using the WideCharToMultiByte
>> conversion API) -- these APIs will use a '?' character for characters
>> that it cannot map to the target character encoding (like the Hiragana
>> characters that you are using).
>
> I have a screenshot from a SmartGit user where 1) the console can show the
> far-east-characters and 2) Git *can* show the characters escaped. Are there
> two versions of Git available or does Gits behaviour depends somehow on the
> system locale?
Does no Git expert know what to do to get it working?
--
Tom
^ permalink raw reply
* Re: Umlaut in filename makes troubles
From: Øyvind A. Holm @ 2009-12-01 7:44 UTC (permalink / raw)
To: rick23, git
In-Reply-To: <200912010815.14515.rick23@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]
On 2009-12-01 08:15:08, rick23@gmx.net wrote:
> I have problems with my repository under slackware vs. windows. I
> created a repo in linux and every time I use it under msysgit, the
> files containing umlauts in the filename are marked as deleted (and
> vice versa).
>
> For instance: the repo perfectly synced under msysgit leads to:
>
> user@sauron:/media/disk-2$ git status |grep Auszug
> # deleted: "trunk/007_Literatur/Auszug aus Ergonomische
> Untersuchung des Lenkgef\374hles.docx"
> # "trunk/007_Literatur/Auszug aus Ergonomische Untersuchung des
> Lenkgef\303\274hles.docx"
>
> in linux. But the file exists and is displayed correctly in the shell
> or in dolphin (my filemanager under X):
>
> user@sauron:/media/disk-2$ ls trunk/007_Literatur/Auszug*
> trunk/007_Literatur/Auszug aus Ergonomische Untersuchung des
> Lenkgefühles.docx
>
> Can you please give me a hint what to do?
Try to specify "utf8" as mount option under Linux. You can also try
experimenting with the "nls" mount option, check out the mount(8) man
page to see how it's used.
Additionally, I found that I need "shortname=mixed" when mounting USB
memory cards. As filenames are case insensitive in Windowsworld and
gadgets using vfat, Linux tend to treat them differently.
Regards,
Øyvind
+-| Øyvind A. Holm <sunny@sunbase.org> - N 60.39548° E 5.31735° |-+
| OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc |
| Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 |
+------------| 760e5d4a-de4c-11de-a982-90e6ba3022ac |-------------+
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Umlaut in filename makes troubles
From: Michael J Gruber @ 2009-12-01 7:54 UTC (permalink / raw)
To: rick23; +Cc: git
In-Reply-To: <200912010815.14515.rick23@gmx.net>
rick23@gmx.net venit, vidit, dixit 01.12.2009 08:15:
> I have problems with my repository under slackware vs. windows. I
> created a repo in linux and every time I use it under msysgit, the
> files containing umlauts in the filename are marked as deleted (and
> vice versa).
>
> For instance: the repo perfectly synced under msysgit leads to:
>
> user@sauron:/media/disk-2$ git status |grep Auszug
> # deleted: "trunk/007_Literatur/Auszug aus Ergonomische
> Untersuchung des Lenkgef\374hles.docx"
> # "trunk/007_Literatur/Auszug aus Ergonomische Untersuchung des
> Lenkgef\303\274hles.docx"
>
> in linux. But the file exists and is displayed correctly in the shell
> or in dolphin (my filemanager under X):
>
> user@sauron:/media/disk-2$ ls trunk/007_Literatur/Auszug*
> trunk/007_Literatur/Auszug aus Ergonomische Untersuchung des
> Lenkgefühles.docx
>
> Can you please give me a hint what to do?
I would say you can give us more info about your setup. If I understand
you correctly, you use the same repo and checkout under linux and
msysgit. What kind of filesystem is this on, what are the mount options?
What is your locale ($LANG) in slackware?
Michael
^ permalink raw reply
* Re: [PATCH/RFC] Add a --bouquet option to git rev-list
From: Michael J Gruber @ 2009-12-01 8:09 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: git
In-Reply-To: <4b143a9c.c401be0a.364f.ffffba5b@mx.google.com>
Nathan W. Panike venit, vidit, dixit 30.11.2009 21:55:
> Add a command line option to rev-list so the command 'git rev-list --bouquet'
> shows all revisions that are ancestors of refs which share history with HEAD.
>
> Signed-off-by: Nathan W. Panike <nathan.panike@gmail.com>
> ---
> I have a repository with the following structure:
>
> B
> /
> A'--A--C
> \
> D
>
> E'--E
>
> Thus the command 'git merge base E A' returns nothing, as there is no common
> history. The E history contains stuff that is derived from the other history
> (A, B, C, or D). Often I find myself doing the following:
Either I don't understand the diagram or your term "derived". If
"derived" means "on some branch of a merge" and E is derived from A, B,
C, or D, then (since B, C, D is derived from A, and from A') E is
derived from A', and they will have a merge base.
Are these diagrams really disconnected from each other?
> git checkout C
> gitk $(include_forks) &
> <View history, make changes, merges, et cetera>
> git checkout E
> <go back to gitk, only see history for B, C, etc>
>
> Now the 'include_forks' command is a bash function in my .bashrc:
>
> include_forks ()
> {
> local head="$(git show -s --pretty=format:'%H' HEAD)";
> echo "HEAD $(git for-each-ref --format='%(refname)' \
> refs/heads refs/remotes | while read ref; do \
> if test "$(git merge-base HEAD ${ref}^{commit})" != ""; \
> then echo ${ref}; fi; done)"
> }
>
> The shell thus intercepts my command and I must restart gitk to see the history
> of E.
>
> With this patch, I can issue the command 'gitk --bouquet' and when I checkout
> E, I can 'reload' in gitk and see the history of E automatically.
What would your patch do in the example you gave above? Which refs would
it cause gitk (rev-list) to show?
Michael
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Johannes Sixt @ 2009-12-01 8:27 UTC (permalink / raw)
To: Thomas Singer; +Cc: git
In-Reply-To: <4B14CA79.6040408@syntevo.com>
Thomas Singer schrieb:
> Thomas Singer wrote:
>> Reece Dunn wrote:
>>> This is a bug in git's character encoding/conversion logic. It looks
>>> like git is taking the source string and converting it to ascii to be
>>> displayed on the console output (e.g. by using the WideCharToMultiByte
>>> conversion API) -- these APIs will use a '?' character for characters
>>> that it cannot map to the target character encoding (like the Hiragana
>>> characters that you are using).
>> I have a screenshot from a SmartGit user where 1) the console can show the
>> far-east-characters and 2) Git *can* show the characters escaped. Are there
>> two versions of Git available or does Gits behaviour depends somehow on the
>> system locale?
>
> Does no Git expert know what to do to get it working?
http://article.gmane.org/gmane.comp.version-control.git/133980 [*]
The possible reason why some one else is seeing correct glyphs with
SmartGit is because it is a Unicode application and the Windows box has
suitable fonts installed and the console is configured with a suitable
font as well.
-- Hannes
[*] I had a botch email infrastructure when I sent this message, and the
copy intended for you went to the waste bin, but I thought I had re-sent
to you in a private mail.
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Johannes Schindelin @ 2009-12-01 8:35 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <0458f16c6ce906997aaf357c0c7368841ae83c36.1259625072.git.bert.wesarg@googlemail.com>
Hi,
On Tue, 1 Dec 2009, Bert Wesarg wrote:
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Thanks. I trust you ran the test suite with valgrind just to make sure?
Ciao,
Dscho
^ permalink raw reply
* Re: Umlaut in filename makes troubles
From: Jochen @ 2009-12-01 8:26 UTC (permalink / raw)
To: git
In-Reply-To: <20091201074420.GC3618@triton>
Øyvind A. Holm wrote:
> On 2009-12-01 08:15:08, rick23@gmx.net wrote:
> > I have problems with my repository under slackware vs. windows. I
> > created a repo in linux and every time I use it under msysgit,
> > the files containing umlauts in the filename are marked as
> > deleted (and vice versa).
> >
> > For instance: the repo perfectly synced under msysgit leads to:
> >
> > user@sauron:/media/disk-2$ git status |grep Auszug
> > # deleted: "trunk/007_Literatur/Auszug aus Ergonomische
> > Untersuchung des Lenkgef\374hles.docx"
> > # "trunk/007_Literatur/Auszug aus Ergonomische Untersuchung
> > des Lenkgef\303\274hles.docx"
> >
> > in linux. But the file exists and is displayed correctly in the
> > shell or in dolphin (my filemanager under X):
> >
> > user@sauron:/media/disk-2$ ls trunk/007_Literatur/Auszug*
> > trunk/007_Literatur/Auszug aus Ergonomische Untersuchung des
> > Lenkgefühles.docx
> >
> > Can you please give me a hint what to do?
>
> Try to specify "utf8" as mount option under Linux.
The automount of KDE 4.2.4 already used utf-8 (I guess the filenames
would be garbled in dolphin otherwise)
> You can also try
> experimenting with the "nls" mount option, check out the mount(8)
> man page to see how it's used.
Ufff, I'm sorry - I'm not sure how to pass this to the automouter. I'd
tried to mount the stick manually (with and without utf) and without
utf8 the filenames are display strange from "ls".
> Additionally, I found that I need "shortname=mixed" when mounting
> USB memory cards. As filenames are case insensitive in Windowsworld
> and gadgets using vfat, Linux tend to treat them differently.
My automouter done it as
/dev/sde on /media/disk-2 type vfat
(rw,nosuid,nodev,uhelper=hal,uid=1000,utf8,shortname=mixed)
So the options look right to me.
Kindest regards
Jochen
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Thomas Singer @ 2009-12-01 8:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B14D381.3010706@viscovery.net>
Johannes Sixt wrote:
> Thomas Singer schrieb:
>> Thomas Singer wrote:
>>> Reece Dunn wrote:
>>>> This is a bug in git's character encoding/conversion logic. It looks
>>>> like git is taking the source string and converting it to ascii to be
>>>> displayed on the console output (e.g. by using the WideCharToMultiByte
>>>> conversion API) -- these APIs will use a '?' character for characters
>>>> that it cannot map to the target character encoding (like the Hiragana
>>>> characters that you are using).
>>> I have a screenshot from a SmartGit user where 1) the console can show the
>>> far-east-characters and 2) Git *can* show the characters escaped. Are there
>>> two versions of Git available or does Gits behaviour depends somehow on the
>>> system locale?
>> Does no Git expert know what to do to get it working?
>
> http://article.gmane.org/gmane.comp.version-control.git/133980 [*]
>
> The possible reason why some one else is seeing correct glyphs with
> SmartGit is because it is a Unicode application and the Windows box has
> suitable fonts installed and the console is configured with a suitable
> font as well.
I wasn't talking about SmartGit, but msysgit on the Windows console. Sorry,
if that wasn't clear.
Is it a German Windows limitation, that far-east characters are not
supported on it (but work fine on a Japanese Windows), are there different
(mysys)Git versions available or is this a configuration issue?
--
Tom
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Thomas Singer @ 2009-12-01 8:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200911282100.23000.j6t@kdbg.org>
Johannes Sixt wrote:
> On Samstag, 28. November 2009, Thomas Singer wrote:
>> I've created a file with unicode characters in its name (using Java):
>>
>> new File(dir, "\u3041\u3042\u3043\u3044").createNewFile();
>> ...
>> $ git add .
>> fatal: unable to stat '????': No such file or directory
>>
>> What should I do to make Git recognize these characters?
>
> You cannot on a German Windows.
>
> You can switch your Windows to Japanese (not the UI, just the codepage
> aka "locale"; yes, that's possible, I have such a setup), but even then the
> characters of the file name will be recorded in Shift-JIS encoding, not UTF-8
> or Unicode. When you later switch back to German, these bytes will be
> interpreted as cp850 or cp1252 text and displayed accordingly.
Who is interpreting the file names? Windows or Git or Java?
--
Tom
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Thomas Singer @ 2009-12-01 9:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B14DA78.70906@syntevo.com>
Thomas Singer wrote:
> Johannes Sixt wrote:
>> You can switch your Windows to Japanese (not the UI, just the codepage
>> aka "locale"; yes, that's possible, I have such a setup), but even then the
>> characters of the file name will be recorded in Shift-JIS encoding, not UTF-8
>> or Unicode. When you later switch back to German, these bytes will be
>> interpreted as cp850 or cp1252 text and displayed accordingly.
>
> Who is interpreting the file names? Windows or Git or Java?
To be more precise: Who is interpreting the bytes in the file names as
characters? Windows, Git or Java?
--
Tom
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Bert Wesarg @ 2009-12-01 9:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0912010934120.4985@pacific.mpi-cbg.de>
On Tue, Dec 1, 2009 at 09:35, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 1 Dec 2009, Bert Wesarg wrote:
>
>> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>
> Thanks. I trust you ran the test suite with valgrind just to make sure?
Not the test suite. But my use case where I found the problem (Ie.
cut-off branch names) which was 'git remote show <remote>'.
There are still invalid reads of size 4. I think the problem is the
flex array member of 'struct ref' and strlen(). If its worth I can
look into this.
Bert
>
> Ciao,
> Dscho
>
^ permalink raw reply
* Re: Umlaut in filename makes troubles
From: Jochen @ 2009-12-01 9:06 UTC (permalink / raw)
To: git
In-Reply-To: <4B14CBA9.6080104@drmicha.warpmail.net>
Michael J Gruber wrote:
> > I have problems with my repository under slackware vs. windows. I
> > created a repo in linux and every time I use it under msysgit,
> > the files containing umlauts in the filename are marked as
> > deleted (and vice versa).
> >
> > For instance: the repo perfectly synced under msysgit leads to:
> >
> > user@sauron:/media/disk-2$ git status |grep Auszug
> > # deleted: "trunk/007_Literatur/Auszug aus Ergonomische
> > Untersuchung des Lenkgef\374hles.docx"
> > # "trunk/007_Literatur/Auszug aus Ergonomische Untersuchung
> > des Lenkgef\303\274hles.docx"
> >
> > in linux. But the file exists and is displayed correctly in the
> > shell or in dolphin (my filemanager under X):
> >
> > user@sauron:/media/disk-2$ ls trunk/007_Literatur/Auszug*
> > trunk/007_Literatur/Auszug aus Ergonomische Untersuchung des
> > Lenkgefühles.docx
> >
> > Can you please give me a hint what to do?
>
> I would say you can give us more info about your setup. If I
> understand you correctly, you use the same repo and checkout under
> linux and msysgit.
Right - I created it under linux on a local directory, cloned it to an
usb-stick and cloned it again under windows.
I then worked under windows (msysgit) and pushed it to the stick
again.
Now I am back an my linux maschine and the files with umlauts in the
filenames are mared as deleted.
> > What kind of filesystem is this on, what are the
> mount options?
/dev/sde on /media/disk-2 type vfat
(rw,nosuid,nodev,uhelper=hal,uid=1000,utf8,shortname=mixed)
mounted by the automounter of KDE 4.2.4
> What is your locale ($LANG) in slackware?
LANG=de_AT.utf-8
Jochen
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Erik Faye-Lund @ 2009-12-01 9:12 UTC (permalink / raw)
To: Thomas Singer; +Cc: Maximilien Noal, git
In-Reply-To: <4B123C80.30607@syntevo.com>
On Sun, Nov 29, 2009 at 10:18 AM, Thomas Singer
<thomas.singer@syntevo.com> wrote:
> Maximilien Noal wrote:
>> About the 'boxes' :
>>
>> The thing is, Windows' files for Asian languages are _not_ installed by
>> default.
>>
>> They can be installed (even while installing Windows), by checking the
>> two checkboxes under the "Supplemtal languages support" groupbox in the
>> "Languages" tab of the "Regional and language options" control panel.
>> *re-take some breath ;-) *
>>
>> It will remove the "boxes" in Explorer and display nice Asian characters.
>
> Thanks, now the characters are showing up fine in the Explorer.
>
> Reece Dunn wrote:
>> This is a bug in git's character encoding/conversion logic. It looks
>> like git is taking the source string and converting it to ascii to be
>> displayed on the console output (e.g. by using the WideCharToMultiByte
>> conversion API) -- these APIs will use a '?' character for characters
>> that it cannot map to the target character encoding (like the Hiragana
>> characters that you are using).
>
> I have a screenshot from a SmartGit user where 1) the console can show the
> far-east-characters and 2) Git *can* show the characters escaped. Are there
> two versions of Git available or does Gits behaviour depends somehow on the
> system locale?
Did you try to make sure your console window used a Unicode font on
your German Windows installation? Asian Windows installations might do
this by default, something at least neither English nor Norwegian
Windows installations seems to do...
You can change the console window font through the properties-menu
that appears when you right click the title-bar.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* [PATCH] Documentation: Fix a few i.e./e.g. mix-ups
From: Michael J Gruber @ 2009-12-01 9:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
A git bundle can be transported by several means (such as e-mail), not
only by snekaernet, so use e.g. instead of i.e.
The mix-up in git-bundle.txt is obvious.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-bundle.txt | 2 +-
Documentation/gitcore-tutorial.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index aee7e4a..c3a066e 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -24,7 +24,7 @@ ssh, rsync, http) cannot be used. This command provides support for
'git-fetch' and 'git-pull' to operate by packaging objects and references
in an archive at the originating machine, then importing those into
another repository using 'git-fetch' and 'git-pull'
-after moving the archive by some means (i.e., by sneakernet). As no
+after moving the archive by some means (e.g., by sneakernet). As no
direct connection between the repositories exists, the user must specify a
basis for the bundle that is held by the destination repository: the
bundle assumes that all objects in the basis are already in the
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index e237394..f762dca 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -602,7 +602,7 @@ $ git tag -s <tagname>
----------------
which will sign the current `HEAD` (but you can also give it another
-argument that specifies the thing to tag, i.e., you could have tagged the
+argument that specifies the thing to tag, e.g., you could have tagged the
current `mybranch` point by using `git tag <tagname> mybranch`).
You normally only do signed tags for major releases or things
--
1.6.6.rc0.274.g71380
^ permalink raw reply related
* Newbie "svn update" question
From: Mikko Oksalahti @ 2009-12-01 9:25 UTC (permalink / raw)
To: git
Hi,
I just started using git for my personal projects at home. Basic usage seems
pretty straight-forward as well as setting up everything. However, I have a
simple question about how do I mimic an "svn update" command on a locally
created repository. Here's what I do:
some_existing_project_dir> git init
some_existing_project_dir> git add .
(about 1000 files added...)
some_existing_project_dir> git commit -a -m "initial commit"
(now I edit 10 files and accidentally delete some files that I'm not aware of)
How do I now get the accidentally deleted files back from the repository without
losing local changes made to 10 files?
I've tried using: "git checkout HEAD ." but my local changes after last commit
will be lost.
I've tried using: "git pull ." but the deleted files are not restored.
So I'm looking for an "svn update" equivalent command that would semantically do
this: "Get the latest version of all files from the repository and merge them
with any local changes I've made to files."
I know a suitable command is available and I'm just a moron who can't read the
manual correctly but help me out anyway :P
Regards,
Mikko
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Bert Wesarg @ 2009-12-01 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jay Soffian, git
In-Reply-To: <7vy6ln2llw.fsf@alter.siamese.dyndns.org>
On Tue, Dec 1, 2009 at 08:34, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>> On Tue, Dec 1, 2009 at 01:21, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> Hmm, the Subject: matches what the code does, but nobody mentions why it
>>> is necessary (iow, what breaks in the current code and what becomes better
>>> if the patch is applied). The blank space before your "S-o-b:" line is
>>> for you to describe these things.
>> Sure. unfortunately the code where the string list is filled is not in
>> the patch. But if you look at the code it should be self-explanatory.
>
> That is _exactly_ why I want the description in the commit log message. I
> don't want commit messages (or lack thereof) to force people to look at
> the code outside the patch.
>
> Otherwise I'll have to ask _you_ to personally give the 7-line explanation
> you just gave us to anybody who runs "git log -p" with the default context
> size after this patch is applied. I do not think you have the bandwidth
> to handle that ;-).
Yes. That makes perfectly sense. Sorry for the hassle.
>
>> There is actually also an other solution: we could first strdup the
>> ref name to the .util member and take this as the input for the
>> abbrev_ref()/string list entry and safe there the strdup.
>
> I too thought something like that may make sense, but it doesn't look like
> so, for two reasons:
>
> - string-list API is a bit cumbersome to use if you allocate the string
> yourself. You will be made responsible for freeing them, and often you
> do so by setting strdup_strings to true immediately before calling
> string_list_clear(), which is kind of ugly;
>
> - The ref abbrev_branch() is called and the address of whose substring is
> taken to be used as "name" in handle_one_branch() is refspec.src, but
> what goes to .util is refname that is refspec.dst---they are different
> strings and one is not a substring of the other.
I don't see you point here. The current code is:
for (ref = stale_refs; ref; ref = ref->next) {
struct string_list_item *item =
string_list_append(abbrev_branch(ref->name), &states->stale);
item->util = xstrdup(ref->name);
}
So 0 == strcmp(item->string, abbrev_ref(item->util, "refs/heads/"))
should be true, shouldn't it?
Bert
^ permalink raw reply
* Re: Newbie "svn update" question
From: Howard Miller @ 2009-12-01 9:45 UTC (permalink / raw)
To: Mikko Oksalahti; +Cc: git
In-Reply-To: <loom.20091201T101313-496@post.gmane.org>
2009/12/1 Mikko Oksalahti <mikko@azila.fi>:
> Hi,
>
> I just started using git for my personal projects at home. Basic usage seems
> pretty straight-forward as well as setting up everything. However, I have a
> simple question about how do I mimic an "svn update" command on a locally
> created repository. Here's what I do:
>
> some_existing_project_dir> git init
> some_existing_project_dir> git add .
>
> (about 1000 files added...)
>
> some_existing_project_dir> git commit -a -m "initial commit"
>
> (now I edit 10 files and accidentally delete some files that I'm not aware of)
>
> How do I now get the accidentally deleted files back from the repository without
> losing local changes made to 10 files?
>
> I've tried using: "git checkout HEAD ." but my local changes after last commit
> will be lost.
>
> I've tried using: "git pull ." but the deleted files are not restored.
>
> So I'm looking for an "svn update" equivalent command that would semantically do
> this: "Get the latest version of all files from the repository and merge them
> with any local changes I've made to files."
>
> I know a suitable command is available and I'm just a moron who can't read the
> manual correctly but help me out anyway :P
>
> Regards,
> Mikko
'git status' should show you what files you have deleted. 'git
checkout filename' should get them back. I can't think of a way of
recovering every file you have just deleted although - I suspect it
might be tricky. Thinks like 'git pull' only apply to remote
repositories and you don't have one of those. You're not thinking of
it the right way (yet) :-)
Howard
^ permalink raw reply
* Re: Newbie "svn update" question
From: Tay Ray Chuan @ 2009-12-01 9:49 UTC (permalink / raw)
To: Mikko Oksalahti; +Cc: git
In-Reply-To: <loom.20091201T101313-496@post.gmane.org>
Hi
On Tue, Dec 1, 2009 at 5:25 PM, Mikko Oksalahti <mikko@azila.fi> wrote:
> How do I now get the accidentally deleted files back from the repository without
> losing local changes made to 10 files?
>
> I've tried using: "git checkout HEAD ." but my local changes after last commit
> will be lost.
>
> I've tried using: "git pull ." but the deleted files are not restored.
>
> So I'm looking for an "svn update" equivalent command that would semantically do
> this: "Get the latest version of all files from the repository and merge them
> with any local changes I've made to files."
Are you looking for a command that
"Restore deleted files, without reverting local changes",
or
"Get the latest version of all files from the repository and merge
them with any local changes I've made to files."?
I would suggest adding the changed files, then doing a checkout.
git add changed.file1
git add changed.file2
git add -p #alternatively, select hunks/changes to add interactively
git checkout HEAD #although using . (current directory) should give
the same result
Note that your changes have only been added to the index, and you need
to commit them. The index/stage is a concept not in svn. See the user
manual for more on this.
I also suspect you are still thinking in svn mode when you said
getting the latest version from the repository. You already have a
repository locally. It is more an issue of syncing your local
repository with the one that you're following. Unlike svn, every time
you commit, your local repository is updated, not the remote one, and
vice-versa.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Umlaut in filename makes troubles
From: Jochen @ 2009-12-01 9:58 UTC (permalink / raw)
To: git
In-Reply-To: <200912010815.14515.rick23@gmx.net>
I found another strange effect...
I made a file with "touch aöäü.txt" and from "git status" I get
# "a\303\266\303\244\303\274.txt"
reported as untracked. But when I start "git gui" I get file displayed with
it's correct name...
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Johannes Sixt @ 2009-12-01 10:00 UTC (permalink / raw)
To: Thomas Singer; +Cc: git
In-Reply-To: <4B14DA1A.4060505@syntevo.com>
Thomas Singer schrieb:
> Is it a German Windows limitation, that far-east characters are not
> supported on it (but work fine on a Japanese Windows), are there different
> (mysys)Git versions available or is this a configuration issue?
It is a matter of configuration.
Since 8 bits are not sufficient to support Japanese alphabet in addition
to the German alphabet, programs that are not Unicode aware -- such as git
-- have to make a decision which alphabet they support. The decision is
made by picking a "codepage".
On German Windows, you are in codepage 850 (in the console). The filenames
(that actually are in Unicode) are converted to bytes according to
codepage 850 *before* git sees them. If your filenames contain Hiragana,
they are substituted by the "unknown character" marker because there is no
place for them in codepage 850.
However, you can install Japanese language support on German Windows. Then
you can change your console to codepage 932:
chcp 932
When you run git from *this* console, Hiragana in the filenames are
converted to cp932 before git sees them. The resulting byte sequence is
different from the one in cp850, but git will be able to see that the file
exists and was modified, and you can 'git add' it.
But if you have files with umlauts, they will not be recognized anymore
because umlauts have no place in cp932.
In neither case can you exchange the repository with Linux if you have
your locale set to UTF-8 on Linux, because neither byte sequence (umlauts
from cp850 or Hiragana from cp932) are valid UTF-8 sequences, let alone
result in the expected glyphs.
Corollary: Stick to ASCII file names.
There have been suggestions to switch the console to codepage 65001
(UTF-8), but I have never heard of success reports. I'm not saying it does
not work, though.
-- Hannes
^ 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