* [PATCH] git-gui: add small screen compatibility
From: Vietor Liu @ 2009-09-28 2:38 UTC (permalink / raw)
To: spearce; +Cc: git, Vietor Liu
The Netbook screen likes 800*480 1024*600. The git-gui's display
should be hide some buttons(ie 'Commit','Push') and 'Status bar'.
Signed-off-by: Vietor Liu <vietor.liu@gmail.com>
---
git-gui/git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 14b92ba..6af9db2 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -3054,7 +3054,7 @@ frame .vpane.lower.diff.body
set ui_diff .vpane.lower.diff.body.t
text $ui_diff -background white -foreground black \
-borderwidth 0 \
- -width 80 -height 15 -wrap none \
+ -width 80 -height 0 -wrap none \
-font font_diff \
-xscrollcommand {.vpane.lower.diff.body.sbx set} \
-yscrollcommand {.vpane.lower.diff.body.sby set} \
--
1.6.5.rc2.dirty
^ permalink raw reply related
* Re: thoughts on a possible "pre-upload" hook
From: Sitaram Chamarty @ 2009-09-28 3:02 UTC (permalink / raw)
To: Adam Brewster; +Cc: git
In-Reply-To: <c376da900909271901q1667ecacw730ba5180a558f3b@mail.gmail.com>
On Mon, Sep 28, 2009 at 7:31 AM, Adam Brewster <adambrewster@gmail.com> wrote:
>> As git is used more and more in corporate-type environments, at some
>> point it becomes convenient to have *branches* (or more accurately,
>> refs) that are not readable. The simplest way to do this (from git's
>> point of view) is to allow a "pre-upload" hook, rather like the
>> "pre-receive" hook or "update" hook.
>>
>
> What's the benefit of this over using multiple repositories?
Over a long pm chat over irc with Ilari, I have come to the same
conclusion. I was hoping there would be some administrative
convenience or workflow convenience to doing this, but whether there
is or not is debatable, and even if there is, there are enough failure
modes to make this have a lot of caveats.
--
Sitaram
^ permalink raw reply
* Re: git clone sending unneeded objects
From: Nicolas Pitre @ 2009-09-28 4:18 UTC (permalink / raw)
To: Jason Merrill; +Cc: Shawn O. Pearce, Matthieu Moy, git, Hin-Tak Leung
In-Reply-To: <4ABEEB92.1020307@redhat.com>
On Sun, 27 Sep 2009, Jason Merrill wrote:
> On 09/26/2009 10:04 PM, Shawn O. Pearce wrote:
> > Actually, if those refs have not changed, quickfetch should kick in
> > and realize that all 410610 objects are reachable locally without
> > errors, permitting the client to avoid the object transfer.
> >
> > However, if *ANY* of those refs were to change to something you
> > don't actually have, quickfetch would fail, and we would need to
> > fetch all 410610 objects.
>
> Right. That seems unfortunate to me; couldn't fetch do a bit more checking
> before it decides to download the whole world again?
The quickfetch test could be turned into a filter so refs that are
already available locally could simply not be fetched on a per ref
basis. But that would be a rather expensive test which couldn't keep
its "quick" qualifier anymore, and so for a case that shouldn't have
happened normally anyway if git didn't have a bug with its clone
operation as I've explained already.
Nicolas
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Robin Rosenberg @ 2009-09-28 6:34 UTC (permalink / raw)
To: Jonas Fonseca
Cc: Mark Struberg, MatthiasSohn, git@vger.kernel.org,
spearce@spearce.org
In-Reply-To: <2c6b72b30909271921y4b191f1fo42b1ffb5f08d3468@mail.gmail.com>
måndag 28 september 2009 04:21:36 skrev Jonas Fonseca <jonas.fonseca@gmail.com>:
> On Sun, Sep 27, 2009 at 15:52, Robin Rosenberg
> <robin.rosenberg.lists@dewire.com> wrote:
> > lördag 26 september 2009 22:10:16 skrev Mark Struberg <struberg@yahoo.de>:
> >> And there is a lot more which imho cannot be set for a project. So checking in the xml sounds like it is way more powerful isn't? And we would have this
> >
> > For JGit, not really. Everything that is not project settings should be left as the default. The only reason is tool constraints. I'm not well versed
> > enough to tell what neatbeans does here.
>
> It is my impression that NetBeans has far better integration with
> maven. In terms of code formatting NetBeans supports
> exporting/importing project specific settings, but I have never
> personally used that.
I was thinking of (project) settings for controlling warnings/errors and formatting.
-- robin
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Robin Rosenberg @ 2009-09-28 6:42 UTC (permalink / raw)
To: Jonas Fonseca
Cc: Mark Struberg, MatthiasSohn, git@vger.kernel.org,
spearce@spearce.org
In-Reply-To: <200909280834.45360.robin.rosenberg.lists@dewire.com>
Oh, dear. I should not reply to e-mail this time of the day....
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Johannes Sixt @ 2009-09-28 6:45 UTC (permalink / raw)
To: Michael Wookey; +Cc: Marius Storm-Olsen, git
In-Reply-To: <d2e97e800909220254sc677abeia220c19f6ef5bd28@mail.gmail.com>
Michael Wookey schrieb:
> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>> Michael Wookey said the following on 22.09.2009 11:17:
>>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>>> Michael, how are you trying to compile git? With the IDE or the
>>>> GNU Make? Which version of MSVC? If you use the IDE, can you make
>>>> sure it doesn't contain the UNICODE define in the compiler
>>>> section of the properties of the projects?
>>> I'm using the VS 2008 Professional IDE (the solution doesn't open
>>> in VS 2005). I made no changes to the build settings. In the
>>> Preprocessor section of the project, UNICODE is defined.
>> Were these projects generated with the Vcproj generator in
>> contrib/buildsystem, with the Qmake generator, or the projects from Frank's
>> repo?
>
> The project was generated from the vcproj generator in
> contrib/buildsystem from git.git/master.
What's the status of this? Do Sebastian Schuberth's patches
http://article.gmane.org/gmane.comp.version-control.msysgit/7152
http://article.gmane.org/gmane.comp.version-control.msysgit/7153
make a difference?
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-am: force egrep to use correct characters set
From: Christian Himpel @ 2009-09-28 6:55 UTC (permalink / raw)
To: Jeff King; +Cc: Christian Himpel, git
In-Reply-To: <20090927074015.GB15393@coredump.intra.peff.net>
On Sun, Sep 27, 2009 at 03:40:15AM -0400, Jeff King wrote:
> On Fri, Sep 25, 2009 at 06:43:20PM +0200, Christian Himpel wrote:
>
> > According to egrep(1) the US-ASCII table is used when LC_ALL=C is set.
> > We do not rely here on the LC_ALL value we get from the environment.
>
> Hmm. Probably makes sense here, as it is a wide enough range that it may
> pick up other stray non-ascii characters in other charsets (though as
> the manpage notes, the likely thing is to pick up A-Z along with a-z,
> which is OK here as we encompass both in our range).
>
> There are two other calls to egrep with brackets (both in
> git-submodule.sh), but they are just [0-7], which is presumably OK in
> just about any charset.
>
> Do you happen to know a charset in which this is a problem, just for
> reference?
No, I don't know any charset with stray ascii-chars. I just listened
attentively, when I read the part about the mixed alphabet characters in
the grep(1) manpage.
I did some quick checks just now. It seems the characters (' ' to '~')
are in any locale, offered by glibc, at the same place.
Maybe, we can just leave the charset as it is and ignore this patch,
until someone complains.
Regards,
chressie
>
> -Peff
^ permalink raw reply
* Re: [PATCH] git-am: force egrep to use correct characters set
From: Jeff King @ 2009-09-28 7:16 UTC (permalink / raw)
To: Christian Himpel; +Cc: git
In-Reply-To: <20090928065519.GA24773@lamagra.informatik.uni-ulm.de>
On Mon, Sep 28, 2009 at 08:55:19AM +0200, Christian Himpel wrote:
> > Do you happen to know a charset in which this is a problem, just for
> > reference?
>
> No, I don't know any charset with stray ascii-chars. I just listened
> attentively, when I read the part about the mixed alphabet characters in
> the grep(1) manpage.
>
> I did some quick checks just now. It seems the characters (' ' to '~')
> are in any locale, offered by glibc, at the same place.
>
> Maybe, we can just leave the charset as it is and ignore this patch,
> until someone complains.
Thanks for looking into it. My question was more of a "how bad is this,
and should we be fixing these other callsites, too". But I think 0-7 is
probably a pretty safe range in any charset.
Usually with portability issues, I am inclined to say "wait for a
problem", as we try to code to match actual reality instead of
documentation or standards. But in this case, we are unlikely to test
with strange charsets (or even know which strange charsets exist;
checking what's in glibc is reasonable, but I have no idea what else is
out there in other countries), and that the resulting bug would be
subtle and hard to find, it probably makes sense to be a little
defensive.
-Peff
^ permalink raw reply
* Re: gitweb atom feeds broken (on repo.or.cz only?)
From: Tay Ray Chuan @ 2009-09-28 7:23 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: git, Petr Baudis, Robert Buchholz
In-Reply-To: <4ABFA258.8020301@hartwork.org>
Hi,
On Mon, Sep 28, 2009 at 1:35 AM, Sebastian Pipping
<webmaster@hartwork.org> wrote:
> i noticed that the atom feeds generated by repo.or.cz's gitweb (e.g.
> [1]) show no content in firefox 3.5.2. this seems to be due to invalid
> xml in it as shown by running [1] through feedvalidator, results at [2].
it's a case of a misspelled tag. In the <author> tag <B> is closed by a </b>.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Michael Wookey @ 2009-09-28 7:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Marius Storm-Olsen, git, Shawn O. Pearce
In-Reply-To: <4AC05BA5.4050106@viscovery.net>
2009/9/28 Johannes Sixt <j.sixt@viscovery.net>:
> Michael Wookey schrieb:
>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>> Michael Wookey said the following on 22.09.2009 11:17:
>>>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>>>> Michael, how are you trying to compile git? With the IDE or the
>>>>> GNU Make? Which version of MSVC? If you use the IDE, can you make
>>>>> sure it doesn't contain the UNICODE define in the compiler
>>>>> section of the properties of the projects?
>>>> I'm using the VS 2008 Professional IDE (the solution doesn't open
>>>> in VS 2005). I made no changes to the build settings. In the
>>>> Preprocessor section of the project, UNICODE is defined.
>>> Were these projects generated with the Vcproj generator in
>>> contrib/buildsystem, with the Qmake generator, or the projects from Frank's
>>> repo?
>>
>> The project was generated from the vcproj generator in
>> contrib/buildsystem from git.git/master.
>
> What's the status of this?
I was hoping that this gets included into git.git because it fixes a
real issue with MSVC builds. Since Junio is away, perhaps Shawn can
take the patch into his interim tree?
BTW - would you mind giving this patch an ack?
> Do Sebastian Schuberth's patches
> http://article.gmane.org/gmane.comp.version-control.msysgit/7152
> http://article.gmane.org/gmane.comp.version-control.msysgit/7153
>
> make a difference?
Unfortunately, no. Those patches do not make a difference.
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Johannes Sixt @ 2009-09-28 8:10 UTC (permalink / raw)
To: Michael Wookey; +Cc: Marius Storm-Olsen, git, Shawn O. Pearce
In-Reply-To: <d2e97e800909280047l5da52ffdxd86589cda4542f46@mail.gmail.com>
Michael Wookey schrieb:
> 2009/9/28 Johannes Sixt <j.sixt@viscovery.net>:
>> Michael Wookey schrieb:
>>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>>> Michael Wookey said the following on 22.09.2009 11:17:
>>>>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>>>>> Michael, how are you trying to compile git? With the IDE or the
>>>>>> GNU Make? Which version of MSVC? If you use the IDE, can you make
>>>>>> sure it doesn't contain the UNICODE define in the compiler
>>>>>> section of the properties of the projects?
>>>>> I'm using the VS 2008 Professional IDE (the solution doesn't open
>>>>> in VS 2005). I made no changes to the build settings. In the
>>>>> Preprocessor section of the project, UNICODE is defined.
>>>> Were these projects generated with the Vcproj generator in
>>>> contrib/buildsystem, with the Qmake generator, or the projects from Frank's
>>>> repo?
>>> The project was generated from the vcproj generator in
>>> contrib/buildsystem from git.git/master.
>> What's the status of this?
>
> I was hoping that this gets included into git.git because it fixes a
> real issue with MSVC builds. Since Junio is away, perhaps Shawn can
> take the patch into his interim tree?
>
> BTW - would you mind giving this patch an ack?
As I said, the patch looks fine. However, in the commit message you say:
MSVC builds define UNICODE which results in the "WIDE" variation of
Win32 API's being used.
But since Marius has built the code without your patch, this justification
must be incomplete. I won't give a formal Ack until this is clarified.
Please work with Marius to figure out why your build uses UNICODE while
Marius's doesn't.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-am: force egrep to use correct characters set
From: Johannes Sixt @ 2009-09-28 8:12 UTC (permalink / raw)
To: Jeff King; +Cc: Christian Himpel, git
In-Reply-To: <20090927074015.GB15393@coredump.intra.peff.net>
Jeff King schrieb:
> On Fri, Sep 25, 2009 at 06:43:20PM +0200, Christian Himpel wrote:
>
>> According to egrep(1) the US-ASCII table is used when LC_ALL=C is set.
>> We do not rely here on the LC_ALL value we get from the environment.
>
> Hmm. Probably makes sense here, as it is a wide enough range that it may
> pick up other stray non-ascii characters in other charsets (though as
> the manpage notes, the likely thing is to pick up A-Z along with a-z,
> which is OK here as we encompass both in our range).
>
> There are two other calls to egrep with brackets (both in
> git-submodule.sh), but they are just [0-7], which is presumably OK in
> just about any charset.
>
> Do you happen to know a charset in which this is a problem, just for
> reference?
It's not so much about charsets than about languages:
Within a bracket expression, a range expression consists
of two characters separated by a hyphen. It matches any
single character that sorts between the two characters,
inclusive, using the locale's collating sequence and
character set. For example, in the default C locale,
[a-d] is equivalent to [abcd]. Many locales sort char-
acters in dictionary order, and in these locales [a-d]
is typically not equivalent to [abcd]; it might be
equivalent to [aBbCcDd], for example. To obtain the
traditional interpretation of bracket expressions, you
can use the C locale by setting the LC_ALL environment
variable to the value C.
For example, in locale de_DE.UTF-8, GNU grep '[a-z]' matches lowercase
letters, uppercase letters (!), and umlauts (!!) because in dictionary
order, 'A' and 'a' are equivalent and 'Ä' sorts after 'A'. (The input must
be UTF-8, of course.)
Given that this applies not only to egrep, but to grep in general (and
perhaps even to other tools that support ranges, like sed), it may be
necessary to audit all range expressions.
The case identified by Christian is certainly important because it is
applied to a file whose contents can be anything, and the purpose of the
check is to identify the text as an mbox file, whose header section can be
only US-ASCII by definition. So, I think it has merit to apply the patch.
-- Hannes
^ permalink raw reply
* [PATCH] typo in hook template
From: Frederik Schwarzer @ 2009-09-28 8:30 UTC (permalink / raw)
To: git
From b4bcd971e3d6358b3381280609e1c0859bee3db8 Mon Sep 17 00:00:00 2001
From: Frederik Schwarzer <schwarzerf@gmail.com>
Date: Mon, 28 Sep 2009 10:25:55 +0200
Subject: [PATCH] typo in hook template
---
templates/hooks--post-receive.sample | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/templates/hooks--post-receive.sample b/templates/hooks--post-
receive.sample
index 18d2e0f..7a83e17 100755
--- a/templates/hooks--post-receive.sample
+++ b/templates/hooks--post-receive.sample
@@ -9,7 +9,7 @@
# For example:
# aa453216d1b3e49e7f6f98441fa56946ddcd6a20
68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master
#
-# see contrib/hooks/ for an sample, or uncomment the next line and
+# see contrib/hooks/ for a sample, or uncomment the next line and
# rename the file to "post-receive".
·
#. /usr/share/doc/git-core/contrib/hooks/post-receive-email
--·
1.6.4.3
^ permalink raw reply related
* Re: Deciding between Git/Mercurial
From: Felipe Contreras @ 2009-09-28 8:36 UTC (permalink / raw)
To: newsgroups; +Cc: git
In-Reply-To: <h9nlhj$heq$1@ger.gmane.org>
On Sun, Sep 27, 2009 at 3:24 PM, Anteru
<newsgroups@catchall.shelter13.net> wrote:
> Hi,
>
> I'm currently evaluating DVCS for a project, and we're at a point where
> it comes down to either Mercurial or Git. Right now, I'm advocating for
> Git, while my co-workers like Mercurial, so I'd like to provide some
> good arguments in favor of git. Unfortunately, I'm not a git expert, so
> I hope I can get some help here ...
IMO the key difference between hg and git is the storage model: hg
stores deltas, while git stores snapshots. That would mean that
certain operations are theoretically faster in git (e.g. checkout,
diff) while others faster in hg, although with git's packed format I
guess there's no operation faster in hg. This means that it doesn't
matter how much hg's python code improves, or if they even re-write
parts in C, they will never be able to match git's performance (unless
they change the storage model, which essentially means changing the
whole design -- won't happen).
All this is just guesses, I've thought about doing some measurements
but I haven't had time.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Matthieu Moy @ 2009-09-28 8:42 UTC (permalink / raw)
To: Felipe Contreras; +Cc: newsgroups, git
In-Reply-To: <94a0d4530909280136s1ff65004q1733bd4ef78bdc07@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> IMO the key difference between hg and git is the storage model: hg
> stores deltas, while git stores snapshots.
Mercurial stores regular snapshots, to make sure you never have to
apply too many deltas to get a snapshot. That's not so different from
what Git does with its packed format (the difference is that Git's
delta are not necessarily against the direct ancestor of the file).
AFAICT, both are snapshot-oriented, but both use a compression
algorithm based on delta.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] git-am: force egrep to use correct characters set
From: Christian Himpel @ 2009-09-28 9:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jeff King, Christian Himpel, git
In-Reply-To: <4AC06FFF.20008@viscovery.net>
On Mon, Sep 28, 2009 at 10:12:47AM +0200, Johannes Sixt wrote:
> Jeff King schrieb:
> > On Fri, Sep 25, 2009 at 06:43:20PM +0200, Christian Himpel wrote:
> >
> >> According to egrep(1) the US-ASCII table is used when LC_ALL=C is set.
> >> We do not rely here on the LC_ALL value we get from the environment.
> >
> > Hmm. Probably makes sense here, as it is a wide enough range that it may
> > pick up other stray non-ascii characters in other charsets (though as
> > the manpage notes, the likely thing is to pick up A-Z along with a-z,
> > which is OK here as we encompass both in our range).
> >
> > There are two other calls to egrep with brackets (both in
> > git-submodule.sh), but they are just [0-7], which is presumably OK in
> > just about any charset.
> >
> > Do you happen to know a charset in which this is a problem, just for
> > reference?
>
> It's not so much about charsets than about languages:
>
> Within a bracket expression, a range expression consists
> of two characters separated by a hyphen. It matches any
> single character that sorts between the two characters,
> inclusive, using the locale's collating sequence and
> character set. For example, in the default C locale,
> [a-d] is equivalent to [abcd]. Many locales sort char-
> acters in dictionary order, and in these locales [a-d]
> is typically not equivalent to [abcd]; it might be
> equivalent to [aBbCcDd], for example. To obtain the
> traditional interpretation of bracket expressions, you
> can use the C locale by setting the LC_ALL environment
> variable to the value C.
>
> For example, in locale de_DE.UTF-8, GNU grep '[a-z]' matches lowercase
> letters, uppercase letters (!), and umlauts (!!) because in dictionary
> order, 'A' and 'a' are equivalent and 'Ä' sorts after 'A'. (The input must
> be UTF-8, of course.)
Thanks for pointing this out. You are right. I must have read the
"dictonary order" part over.
> Given that this applies not only to egrep, but to grep in general (and
> perhaps even to other tools that support ranges, like sed), it may be
> necessary to audit all range expressions.
After doing a quick:
LC_ALL=C find . -name '*.sh' -exec \
egrep -Hne '(grep|awk|sed).*\[.*-.*\]' {} \;
As far as I can see, range expressions are used:
1. to replace or grep hexadecimal numbers (SHA1 sums). This shouldn't
be a problem, if we can assume that these numbers are never malformed.
2. to replace or grep numbers (with digits). This shouldn't be a
problem, since digits should be in dictionary order in every language
(?!).
3. in git-rebase--interactive.sh:742 to grep for a previously generated
string. So it should be safe here.
> The case identified by Christian is certainly important because it is
> applied to a file whose contents can be anything, and the purpose of the
> check is to identify the text as an mbox file, whose header section can be
> only US-ASCII by definition. So, I think it has merit to apply the patch.
Yes. It seems that this is the only place where it is important to match
just the ASCII printable characters.
Regards,
chressie
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Michael Wookey @ 2009-09-28 9:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Marius Storm-Olsen, git, Shawn O. Pearce
In-Reply-To: <4AC06F65.1020301@viscovery.net>
2009/9/28 Johannes Sixt <j.sixt@viscovery.net>:
> Michael Wookey schrieb:
>> 2009/9/28 Johannes Sixt <j.sixt@viscovery.net>:
>>> Michael Wookey schrieb:
>>>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>>>> Michael Wookey said the following on 22.09.2009 11:17:
>>>>>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>>>>>> Michael, how are you trying to compile git? With the IDE or the
>>>>>>> GNU Make? Which version of MSVC? If you use the IDE, can you make
>>>>>>> sure it doesn't contain the UNICODE define in the compiler
>>>>>>> section of the properties of the projects?
>>>>>> I'm using the VS 2008 Professional IDE (the solution doesn't open
>>>>>> in VS 2005). I made no changes to the build settings. In the
>>>>>> Preprocessor section of the project, UNICODE is defined.
>>>>> Were these projects generated with the Vcproj generator in
>>>>> contrib/buildsystem, with the Qmake generator, or the projects from Frank's
>>>>> repo?
>>>> The project was generated from the vcproj generator in
>>>> contrib/buildsystem from git.git/master.
>>> What's the status of this?
>>
>> I was hoping that this gets included into git.git because it fixes a
>> real issue with MSVC builds. Since Junio is away, perhaps Shawn can
>> take the patch into his interim tree?
>>
>> BTW - would you mind giving this patch an ack?
>
> As I said, the patch looks fine. However, in the commit message you say:
>
> MSVC builds define UNICODE which results in the "WIDE" variation of
> Win32 API's being used.
>
> But since Marius has built the code without your patch, this justification
> must be incomplete. I won't give a formal Ack until this is clarified.
>
> Please work with Marius to figure out why your build uses UNICODE while
> Marius's doesn't.
Well, the command line builds have always worked fine. The definition
of UNICODE was limited to building in the IDE. That detail was
unfortunately missing from the original commit message.
It seems that the project file that is generated by Vcproj.pm
(inadvertently?) defines UNICODE. Perhaps the patch below is better
than my original workaround. If you think so, I'll create a formal
patch.
[ sorry if the patch wraps ]
diff --git a/contrib/buildsystems/Generators/Vcproj.pm
b/contrib/buildsystems/Generators/Vcproj.pm
index 00ec0c1..a648756 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -173,7 +173,7 @@ sub createLibProject {
Optimization="0"
InlineFunctionExpansion="1"
AdditionalIncludeDirectories="$includes"
-
PreprocessorDefinitions="UNICODE,WIN32,_DEBUG,$defines"
+ PreprocessorDefinitions="WIN32,_DEBUG,$defines"
MinimalRebuild="true"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
^ permalink raw reply related
* Re: [PATCH] git-am: force egrep to use correct characters set
From: Johannes Sixt @ 2009-09-28 9:53 UTC (permalink / raw)
To: Christian Himpel; +Cc: Jeff King, git
In-Reply-To: <20090928093216.GA31459@lamagra.informatik.uni-ulm.de>
Christian Himpel schrieb:
> After doing a quick:
>
> LC_ALL=C find . -name '*.sh' -exec \
> egrep -Hne '(grep|awk|sed).*\[.*-.*\]' {} \;
>
> As far as I can see, range expressions are used:
0. The test suite scripts are not critical because test-lib.sh sets LANG=C
LC_ALL=C
> 1. to replace or grep hexadecimal numbers (SHA1 sums). This shouldn't
> be a problem, if we can assume that these numbers are never malformed.
The assumption is valid if the input is piped from a git command, and such
uses aren't critical.
> 2. to replace or grep numbers (with digits). This shouldn't be a
> problem, since digits should be in dictionary order in every language
> (?!).
I agree.
> 3. in git-rebase--interactive.sh:742 to grep for a previously generated
> string. So it should be safe here.
I agree.
>> The case identified by Christian is certainly important because it is
>> applied to a file whose contents can be anything, and the purpose of the
>> check is to identify the text as an mbox file, whose header section can be
>> only US-ASCII by definition. So, I think it has merit to apply the patch.
>
> Yes. It seems that this is the only place where it is important to match
> just the ASCII printable characters.
There is another place in git-am.sh where a sed expression with a range
looks at the input file, doesn't it? Isn't it critical, too?
if test -f "$dotest/rebasing" &&
commit=$(sed -e 's/^From \([0-9a-f]*\) .*/\1/' \
-e q "$dotest/$msgnum") &&
test "$(git cat-file -t "$commit")" = commit
then ...
-- Hannes
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Michael Wookey @ 2009-09-28 9:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Marius Storm-Olsen, git, Shawn O. Pearce
In-Reply-To: <d2e97e800909280250j4e432deeo230cbc622b6e690a@mail.gmail.com>
> It seems that the project file that is generated by Vcproj.pm
> (inadvertently?) defines UNICODE. Perhaps the patch below is better
> than my original workaround. If you think so, I'll create a formal
> patch.
>
> [ sorry if the patch wraps ]
>
scrub the previous patch... there were more instances of UNICODE
defined (for release and debug builds). The patch below takes care of
them all.
diff --git a/contrib/buildsystems/Generators/Vcproj.pm
b/contrib/buildsystems/Generators/Vcproj.pm
index 00ec0c1..a215911 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -173,7 +173,7 @@ sub createLibProject {
Optimization="0"
InlineFunctionExpansion="1"
AdditionalIncludeDirectories="$includes"
-
PreprocessorDefinitions="UNICODE,WIN32,_DEBUG,$defines"
+ PreprocessorDefinitions="WIN32,_DEBUG,$defines"
MinimalRebuild="true"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
@@ -239,7 +239,7 @@ sub createLibProject {
InlineFunctionExpansion="1"
EnableIntrinsicFunctions="true"
AdditionalIncludeDirectories="$includes"
-
PreprocessorDefinitions="UNICODE,WIN32,NDEBUG,$defines"
+ PreprocessorDefinitions="WIN32,NDEBUG,$defines"
RuntimeLibrary="0"
EnableFunctionLevelLinking="true"
UsePrecompiledHeader="0"
@@ -395,7 +395,7 @@ sub createAppProject {
Optimization="0"
InlineFunctionExpansion="1"
AdditionalIncludeDirectories="$includes"
-
PreprocessorDefinitions="UNICODE,WIN32,_DEBUG,$defines"
+ PreprocessorDefinitions="WIN32,_DEBUG,$defines"
MinimalRebuild="true"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
@@ -466,7 +466,7 @@ sub createAppProject {
InlineFunctionExpansion="1"
EnableIntrinsicFunctions="true"
AdditionalIncludeDirectories="$includes"
-
PreprocessorDefinitions="UNICODE,WIN32,NDEBUG,$defines"
+ PreprocessorDefinitions="WIN32,NDEBUG,$defines"
RuntimeLibrary="0"
^ permalink raw reply related
* Press request
From: Editor HjemmePC @ 2009-09-28 9:32 UTC (permalink / raw)
To: git
Hi, I am a edtitor for the norwegian computer magazine called "HjemmePC"
Each month I am collecting good software to be included in our magazine. Sometimes we also ask about full version covermount, which means we are given an old full version of you program, with upgrade offer to the latest for our readers. I am excited to ask if this is something that could be of interest for you. You will off course be given editorial review and space in both our magazine and our software section on web. I hope to hear from you soon
Best Regards
Kent Kjernes
Editor of Computer Magazine "HjemmePC"
press@hjemmepc.no
Fax: +47 67 21 40 83
About the magazine
HjemmePC is published by HM Nordic
(http://www.hm-media.no/eway/?pid=196) and covers the increasingly active and growing home market. Using easily understandable language, HjemmePC increases its readers' knowledge of computers and the latest innovations in computers and computer products.
Internet: www.hjemmepc.no
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Johannes Schindelin @ 2009-09-28 10:08 UTC (permalink / raw)
To: Felipe Contreras; +Cc: newsgroups, git
In-Reply-To: <94a0d4530909280136s1ff65004q1733bd4ef78bdc07@mail.gmail.com>
Hi,
I tried to refrain from commenting in this thread, because I do not want
to encourage people just to use msysGit and never even attempt to fix
their own issues.
But I cannot let this go uncommented:
On Mon, 28 Sep 2009, Felipe Contreras wrote:
> IMO the key difference between hg and git is the storage model: hg
> stores deltas, while git stores snapshots. That would mean that certain
> operations are theoretically faster in git (e.g. checkout, diff) while
> others faster in hg, although with git's packed format I guess there's
> no operation faster in hg. This means that it doesn't matter how much
> hg's python code improves, or if they even re-write parts in C, they
> will never be able to match git's performance (unless they change the
> storage model, which essentially means changing the whole design --
> won't happen).
That is wrong. "git log -- <file>" will always be slightly faster in
Mercurial, for all the reasons you mentioned.
In addition, Mercurial _has_ parts re-written in C for performance, which
renders it not-exactly more portable if you ask me. Last time I checked,
there was no way to compile a Python module with MinGW (or for that
matter, Python itself), but you needed MSVC...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Marius Storm-Olsen @ 2009-09-28 10:21 UTC (permalink / raw)
To: Michael Wookey; +Cc: Johannes Sixt, git, Shawn O. Pearce
In-Reply-To: <d2e97e800909280255h70e4c006m98cde895b95fef29@mail.gmail.com>
Michael Wookey said the following on 28.09.2009 11:55:
>> It seems that the project file that is generated by Vcproj.pm
>> (inadvertently?) defines UNICODE. Perhaps the patch below is better
>> than my original workaround. If you think so, I'll create a formal
>> patch.
>>
>> [ sorry if the patch wraps ]
>>
>
> scrub the previous patch... there were more instances of UNICODE
> defined (for release and debug builds). The patch below takes care of
> them all.
Yup, IMO this is the correct patch, since it will follow the Makefile
more closely. So, if we then decide to add UNICODE in the Makefile,
the generated files will follow.
Make it into a proper patch, and I'll ack.
--
.marius
^ permalink raw reply
* Re: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Baz @ 2009-09-28 10:36 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: Shawn O. Pearce, git, mstormo
In-Reply-To: <bdca99240909260245i6ba10dd4j1b2ee9e74ea5282d@mail.gmail.com>
2009/9/26 Sebastian Schuberth <sschuberth@gmail.com>:
> On Sat, Sep 26, 2009 at 02:05, Shawn O. Pearce <spearce@spearce.org> wrote:
>
>> Odd. If I copy and paste from Thunderbird, its fine. But if I
>> save the body out as an attachment from mutt, it fails.
>>
>> I wonder if it has to do with the From header appearing in the top
>> of the body; this header has to be escaped with a leading space in
>> mbox format. It looks like Thunderbird might be doing some magic to
>> remove that leading space from the context lines, while mutt isn't.
FYI: the Thunderbird version included this header:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
The format=flowed part shows that Thunderbird is reformatting
whitespace. You can disable that:
http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email
'flowed' is a lossy transformation of text, so git won't attempt to
fix patches that have been mangled that way. There's a longer
explanation from Junio here:
http://kerneltrap.org/mailarchive/git/2008/2/15/867294
Hope this helps,
Baz
>>
>> Next time, don't include the first From line?
>
> Will try. So what about these two patches? Should I re-send them with
> the first "From" stripped?
>
> Or will *.patch files that are attached to emails, instead of sending
> the patch inline, be accepted?
>
> --
> Sebastian Schuberth
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Press request
From: Johan Herland @ 2009-09-28 10:40 UTC (permalink / raw)
To: git, press
In-Reply-To: <20090928113233.KOUHQXVSQQEOVI@hjemmepc.no>
On Monday 28 September 2009, Editor HjemmePC wrote:
> Hi, I am a edtitor for the norwegian computer magazine called
> "HjemmePC" Each month I am collecting good software to be included in
> our magazine. Sometimes we also ask about full version covermount,
> which means we are given an old full version of you program, with
> upgrade offer to the latest for our readers. I am excited to ask if
> this is something that could be of interest for you. You will off
> course be given editorial review and space in both our magazine and
> our software section on web. I hope to hear from you soon
It's hard to decipher what you're really asking for here, but I'll take
a stab at it.
If you're asking for a version of our software to put on the CD-ROM that
comes with your magazine, then I can only say that our software is free
software (as governed by the GPLv2 license), and that you can put it on
your CD-ROM subject to the same terms as any other GPL program on your
CD-ROMs.
If you're looking for more information on the Git project, please refer
to the project's homepage at git-scm.com.
Otherwise, feel free to ask specific to-the-point questions directly on
this mailing list.
Hope this helps,
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] generators/vcproj.pm: remove UNICODE from build
From: Michael Wookey @ 2009-09-28 10:46 UTC (permalink / raw)
To: git
Defining UNICODE for MSVC IDE builds results in certain Win32 WIDE API's
receiving ANSI strings. The result of which is an invalid use of the API
and will end in either data corruption or an application crash.
Prevent the use of WIDE API's when building with the MSVC IDE for
compatibility with msysGit.
Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
---
contrib/buildsystems/Generators/Vcproj.pm | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/buildsystems/Generators/Vcproj.pm
b/contrib/buildsystems/Generators/Vcproj.pm
index 00ec0c1..a215911 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -173,7 +173,7 @@ sub createLibProject {
Optimization="0"
InlineFunctionExpansion="1"
AdditionalIncludeDirectories="$includes"
- PreprocessorDefinitions="UNICODE,WIN32,_DEBUG,$defines"
+ PreprocessorDefinitions="WIN32,_DEBUG,$defines"
MinimalRebuild="true"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
@@ -239,7 +239,7 @@ sub createLibProject {
InlineFunctionExpansion="1"
EnableIntrinsicFunctions="true"
AdditionalIncludeDirectories="$includes"
- PreprocessorDefinitions="UNICODE,WIN32,NDEBUG,$defines"
+ PreprocessorDefinitions="WIN32,NDEBUG,$defines"
RuntimeLibrary="0"
EnableFunctionLevelLinking="true"
UsePrecompiledHeader="0"
@@ -395,7 +395,7 @@ sub createAppProject {
Optimization="0"
InlineFunctionExpansion="1"
AdditionalIncludeDirectories="$includes"
- PreprocessorDefinitions="UNICODE,WIN32,_DEBUG,$defines"
+ PreprocessorDefinitions="WIN32,_DEBUG,$defines"
MinimalRebuild="true"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
@@ -466,7 +466,7 @@ sub createAppProject {
InlineFunctionExpansion="1"
EnableIntrinsicFunctions="true"
AdditionalIncludeDirectories="$includes"
- PreprocessorDefinitions="UNICODE,WIN32,NDEBUG,$defines"
+ PreprocessorDefinitions="WIN32,NDEBUG,$defines"
RuntimeLibrary="0"
EnableFunctionLevelLinking="true"
UsePrecompiledHeader="0"
--
1.6.5.rc2
^ permalink raw reply related
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