* Re: Unable to checkout a particular SVN revision
From: Marc Liyanage @ 2009-12-01 4:59 UTC (permalink / raw)
To: git; +Cc: Daniele Segato
In-Reply-To: <1259513411.32532.22.camel@localhost>
On 29.11.2009, at 08:50, Daniele Segato wrote:
> You had to understand the difference between a distributed version
> control system (git) and a centralized version control system (svn).
I understand that, I use (pure) git for all my personal projects, and it works great.
And even as a front end for SVN, I am *very* happy with what I got from git-svn so far, I think it is an excellent tool, even better than the actual SVN client. I track an SVN repository in my local git master branch, then branch off locally for development, send patches for review, reorder/consolidate/squash commits back onto my master branch and then dcommit that back to SVN. All that is great.
I would like to understand why
git svn clone -r n <url>
does not work as expected while
git svn clone -r m <url>
does work perfectly fine, if that m revision number happens to have been committed on the particular SVN branch I cloned (you left off that -r in your git svn clone examples). As it is, I have to hunt for the next lower or higher revision number that happens to be on that branch.
I might be doing a poor job explaining what my question is... Basically, what prevents that operation from doing the same thing that SVN does? Lack of information, i.e. should I just clone higher up in the tree?
______________________________
Marc Liyanage
www.entropy.ch
skype mliyanage
iChat liyanage@mac.com
^ permalink raw reply
* Re: "git merge" merges too much!
From: Dmitry Potapov @ 2009-12-01 5:47 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <m1NFGXS-000kn2C@most.weird.com>
On Mon, Nov 30, 2009 at 07:24:14PM -0500, Greg A. Woods wrote:
>
> Things get even weirder if you happen to be playing with older branches
> too -- most build tools don't have ability to follow files that go back
> in time as they assume any product files newer than the sources are
> already up-to-date, no matter how much older the sources might become on
> a second build.
No, files do not go back in time when you switch between branches. The
timestamp on files is the time when they are written to your working
tree (and it is so with other VCSes that I worked with, so I do not
know where you get idea of file timestamps going back in time). Thus any
building tool such as 'make' should work fine provided you have correct
dependencies. I have switched between widely diversed branches, and I
have never had any problem with that.
Dmitry
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Bert Wesarg @ 2009-12-01 6:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jay Soffian, git
In-Reply-To: <7viqcrbl22.fsf@alter.siamese.dyndns.org>
On Tue, Dec 1, 2009 at 01:21, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
The entries of the stale branches string list are made of the stale
refs, which are immediately free'ed after the string list creation.
Therefore the list entries use memory after free. This resulted for me
in a corrupted branch list for 'git remote show' (duplicate entries
and cut-off entries). The .util member of the string list entries are
also strdup() of the branch (full)name itself, but at clear time we
request not to free the .util member. Which results in a memory leak.
>> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>
> 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.
>
>> ---
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.
Bert
>> builtin-remote.c | 6 ++++--
>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/builtin-remote.c b/builtin-remote.c
>> index 7916626..bb72e27 100644
>> --- a/builtin-remote.c
>> +++ b/builtin-remote.c
>> @@ -272,7 +272,9 @@ static int get_ref_states(const struct ref *remote_refs, struct ref_states *stat
>> die("Could not get fetch map for refspec %s",
>> states->remote->fetch_refspec[i]);
>>
>> - states->new.strdup_strings = states->tracked.strdup_strings = 1;
>> + states->new.strdup_strings =
>> + states->tracked.strdup_strings =
>> + states->stale.strdup_strings = 1;
>> for (ref = fetch_map; ref; ref = ref->next) {
>> unsigned char sha1[20];
>> if (!ref->peer_ref || read_ref(ref->peer_ref->name, sha1))
>> @@ -768,7 +770,7 @@ static void clear_push_info(void *util, const char *string)
>> static void free_remote_ref_states(struct ref_states *states)
>> {
>> string_list_clear(&states->new, 0);
>> - string_list_clear(&states->stale, 0);
>> + string_list_clear(&states->stale, 1);
>> string_list_clear(&states->tracked, 0);
>> string_list_clear(&states->heads, 0);
>> string_list_clear_func(&states->push, clear_push_info);
>> --
>> 1.6.6.rc0.253.g1ec3
>
^ permalink raw reply
* Umlaut in filename makes troubles
From: rick23 @ 2009-12-01 7:15 UTC (permalink / raw)
To: git
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?
TIA
^ permalink raw reply
* 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
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