* Re: Distribution size
From: Marius Storm-Olsen @ 2009-09-28 12:48 UTC (permalink / raw)
To: Thomas Singer; +Cc: git, Johannes Schindelin, Marc Weber
In-Reply-To: <4ABE3091.5040600@syntevo.com>
Thomas Singer said the following on 26.09.2009 17:17:
>> Funny. Git for Windows is less than 12MB [*1*].
>
> Well, the portable Git bundle compressed with 7zip is approx. 11MB,
> the Git installer (maybe also using 7zip internally) is at approx.
> the same size. Unpacked/installed on disk they are at 138MB/131MB.
> If you try to compress it with zip, it will reduce to approx. 70MB
> which still is quite large.
>
> We are interested, too, in having a small(er) bundle, because we
> want to distribute Git binaries with our Git GUI front-end,
> SmartGit, so the user will (have the option to) get an
> all-inclusive-bundle.
[Please, never ever top-post on the Git mailing list, thanks]
Most of the git-*.exe are identical duplicates, so most of that can be
nuked. Also, you don't need everything in msysgit to distribute, only
for development. You should be able to make a fairly small
distribution for usage only.
--
.marius
^ permalink raw reply
* Re: [JGIT PATCH 1/9] mavenizing step 1: moved over the initial poms from Jasons branch Signed-off-by: Mark Struberg <struberg@yahoo.de>
From: Jonas Fonseca @ 2009-09-28 12:46 UTC (permalink / raw)
To: Mark Struberg; +Cc: Robin Rosenberg, git, spearce, Jason van Zyl
In-Reply-To: <901099.90084.qm@web27801.mail.ukl.yahoo.com>
On Sat, Sep 26, 2009 at 15:50, Mark Struberg <struberg@yahoo.de> wrote:
> Hi Robin!
>
> a) Actually git-format-patch only created 0001-0009 so there is no 0/9.
For larger patch series, it is good practice (at least on git@vger) to
provide a "cover letter" (see git-format-patch --cover-letter) to give
reviewers of the patch series an idea of what code is touched and for
you to give additional information, such as the state of the patch
series.
> b) 2/9 is the actual directory structure moving. I received it, but since it is pretty large (330k already with -M -l0) it might got filtered out?
> If so then may I ask you to please fetch it from http://github.com/sonatype/JGit branch 'mavenize'? It has the same content I sent to the list.
Some general notes on the patch series. First, I am glad you posted it
to have something to discuss and as I have stated in a private mail I
am glad you are doing this. However, I also think it needs a lot more
polish before being integrated.
While I understand that you want to credit Jason for doing the initial
probe into fully mavenizing JGit, I now think it is wrong to base the
patch series on his patch. My first impression is that it actually
removes features (by not keeping the JGit specific settings), which
you then try to amend later in the patch series.
In terms of making the patch series more manageable for you, I think
the best approach is to start with the patches not relevant to the
mavenizing (renaming PathSuffixTestCase). After this comes patches
which only touch pom.xml files. For example, move
jgit-maven/jgit/pom.xml to the top-level pom.xml, extract relevant
pieces to org.spearce.jgit/pom.xml and org.spearce.jgit.test/pom.xml,
improving the pom.xml`s by adding checkstyle/<scm> integration, and
mavenizing org.spearce.jgit.pgm/. The final and most invasive parts
(renaming/(re)moving code/eclipse files etc) should come last!
Taking this approach Robin and Spearce can start integrating initial
patces and we can all start testing the "mavenization" sooner rather
than after deciding how to rename things and whether or not to remove
certain files.
The above is a proposal and if you and other agree that it is the
right approach _and_ you do not feel you have the time necessary to
realize it, I am willing to work on it.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] generators/vcproj.pm: remove UNICODE from build
From: Marius Storm-Olsen @ 2009-09-28 12:39 UTC (permalink / raw)
To: Michael Wookey; +Cc: git
In-Reply-To: <d2e97e800909280346s12c205f2gf95ff4c135d4625c@mail.gmail.com>
Michael Wookey said the following on 28.09.2009 12:46:
> 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>
> ---
After manually editing the patch until it applied (some headers which
gt-am didn't like):
Acked-by: Marius Storm-Olsen <mstormo@gmail.com>
--
.marius
^ permalink raw reply
* Re: [PATCH] git-am: force egrep to use correct characters set
From: Christian Himpel @ 2009-09-28 12:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Christian Himpel, Jeff King, git
In-Reply-To: <4AC0877E.7020204@viscovery.net>
On Mon, Sep 28, 2009 at 11:53:02AM +0200, Johannes Sixt wrote:
> Christian Himpel schrieb:
> >> 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 ...
It seems to be the line generated from 'git format-patch' that is tested
here. It specifies the SHA1 of the commit that is converted into a mbox
patch by 'format-patch'. Hence, I don't see it critical here (until
someone edits this line by hand).
Regards,
chressie
^ permalink raw reply
* [PATCH 2/2] Make just opening the generated MSVC solution file not modify it
From: Marius Storm-Olsen @ 2009-09-28 11:34 UTC (permalink / raw)
To: git, spearce, sschuberth; +Cc: msysgit
In-Reply-To: <cover.1254137149.git.mstormo@gmail.com>
From: Sebastian Schuberth <sschuberth@gmail.com>
The format of the generated MSVC solution file is fixed in a way that
just opening it in Visual Studio and immediately closing it again
without performing any modifications does not trigger a prompt to save
the solution file. This behavior was caused by several minor
incompatibilities between the generated file and what Visual Studio
2008 expected, so Visual Studio transparently fixed the file format,
marking it internally as modified.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Acked-by: Marius Storm-Olsen <mstormo@gmail.com>
---
contrib/buildsystems/Generators/Vcproj.pm | 42 +++++++---------------------
1 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/contrib/buildsystems/Generators/Vcproj.pm b/contrib/buildsystems/Generators/Vcproj.pm
index 50daa03..d53ff2c 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -571,45 +571,29 @@ sub createGlueProject {
print F "\"${libname}\", \"${libname}\\${libname}.vcproj\", \"${uuid}\"";
print F "$SLN_POST";
}
+ my $uuid_libgit = $build_structure{"LIBS_libgit_GUID"};
+ my $uuid_xdiff_lib = $build_structure{"LIBS_xdiff_lib_GUID"};
foreach (@apps) {
my $appname = $_;
my $uuid = $build_structure{"APPS_${appname}_GUID"};
print F "$SLN_PRE";
- print F "\"${appname}\", \"${appname}\\${appname}.vcproj\", \"${uuid}\"";
+ print F "\"${appname}\", \"${appname}\\${appname}.vcproj\", \"${uuid}\"\n";
+ print F " ProjectSection(ProjectDependencies) = postProject\n";
+ print F " ${uuid_libgit} = ${uuid_libgit}\n";
+ print F " ${uuid_xdiff_lib} = ${uuid_xdiff_lib}\n";
+ print F " EndProjectSection";
print F "$SLN_POST";
}
print F << "EOM";
Global
- GlobalSection(SolutionConfiguration) = preSolution
- ConfigName.0 = Debug|Win32
- ConfigName.1 = Release|Win32
+ GlobalSection(SolutionConfigurationPlatforms) = preSolution
+ Debug|Win32 = Debug|Win32
+ Release|Win32 = Release|Win32
EndGlobalSection
- GlobalSection(ProjectDependencies) = postSolution
EOM
- foreach (@{$build_structure{"APPS"}}) {
- my $appname = $_;
- my $appname_clean = $_;
- $appname_clean =~ s/\//_/g;
- $appname_clean =~ s/\.exe//;
-
- my $uuid = $build_structure{"APPS_${appname_clean}_GUID"};
- my $dep_index = 0;
- foreach(@{$build_structure{"APPS_${appname}_LIBS"}}) {
- my $libname = $_;
- $libname =~ s/\//_/g;
- $libname =~ s/\.(a|lib)//;
- my $libuuid = $build_structure{"LIBS_${libname}_GUID"};
- if (defined $libuuid) {
- print F "\t\t${uuid}.${dep_index} = ${libuuid}\n";
- $dep_index += 1;
- }
- }
- }
-
print F << "EOM";
- EndGlobalSection
- GlobalSection(ProjectConfiguration) = postSolution
+ GlobalSection(ProjectConfigurationPlatforms) = postSolution
EOM
foreach (@libs) {
my $libname = $_;
@@ -630,10 +614,6 @@ EOM
print F << "EOM";
EndGlobalSection
- GlobalSection(ExtensibilityGlobals) = postSolution
- EndGlobalSection
- GlobalSection(ExtensibilityAddIns) = postSolution
- EndGlobalSection
EndGlobal
EOM
close F;
--
1.6.5.rc2.177.ga9dd6
^ permalink raw reply related
* [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Marius Storm-Olsen @ 2009-09-28 11:34 UTC (permalink / raw)
To: git, spearce, sschuberth; +Cc: msysgit
In-Reply-To: <cover.1254137149.git.mstormo@gmail.com>
From: Sebastian Schuberth <sschuberth@gmail.com>
In order to be able to open the generated solution file by double-
clicking it in Windows Explorer, all project files need to use DOS
line-endings and a comment about the Visual Studio version needs to
be added to the header of the solution file. This also fixes the icon
that is displayed for the solution file in Windows Explorer.
Note that opening the solution file from a running instance of Visual
Studio already worked before.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Acked-by: Marius Storm-Olsen <mstormo@gmail.com>
---
contrib/buildsystems/Generators/Vcproj.pm | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/contrib/buildsystems/Generators/Vcproj.pm b/contrib/buildsystems/Generators/Vcproj.pm
index 00ec0c1..50daa03 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -131,6 +131,7 @@ sub createLibProject {
$includes =~ s/-I//g;
mkdir "$target" || die "Could not create the directory $target for lib project!\n";
open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+ binmode F, ":crlf";
print F << "EOM";
<?xml version="1.0" encoding = "Windows-1252"?>
<VisualStudioProject
@@ -353,6 +354,7 @@ sub createAppProject {
$includes =~ s/-I//g;
mkdir "$target" || die "Could not create the directory $target for lib project!\n";
open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+ binmode F, ":crlf";
print F << "EOM";
<?xml version="1.0" encoding = "Windows-1252"?>
<VisualStudioProject
@@ -537,7 +539,7 @@ sub createGlueProject {
print "Generate solutions file\n";
$rel_dir = "..\\$rel_dir";
$rel_dir =~ s/\//\\/g;
- my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n";
+ my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n# Visual Studio 2008\n";
my $SLN_PRE = "Project(\"{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\") = ";
my $SLN_POST = "\nEndProject\n";
@@ -560,6 +562,7 @@ sub createGlueProject {
@apps = @tmp;
open F, ">git.sln" || die "Could not open git.sln for writing!\n";
+ binmode F, ":crlf";
print F "$SLN_HEAD";
foreach (@libs) {
my $libname = $_;
--
1.6.5.rc2.177.ga9dd6
^ permalink raw reply related
* [PATCH 0/2] MSVC generator fixups
From: Marius Storm-Olsen @ 2009-09-28 11:34 UTC (permalink / raw)
To: git, spearce, sschuberth; +Cc: msysgit, Marius Storm-Olsen
In-Reply-To: <4ABB84F4.7080403@gmail.com>
The generated solution file was valid, but not exactly in the way the
2008 IDE wanted them, so the IDE would query to save the solution file
even though the user never touched the solution/projects.
These two patches ensures that the solution file is in the way the IDE
wants them, so we avoid the naging.
The two patches didn't apply for me in the way they were sent. I
manually applied them ontop of master, and added an Acked-by.
Thanks!
Sebastian Schuberth (2):
Make generated MSVC solution file open from Windows Explorer
Make just opening the generated MSVC solution file not modify it
contrib/buildsystems/Generators/Vcproj.pm | 47 +++++++++-------------------
1 files changed, 15 insertions(+), 32 deletions(-)
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Dilip M @ 2009-09-28 11:32 UTC (permalink / raw)
To: newsgroups, git
In-Reply-To: <h9nlhj$heq$1@ger.gmane.org>
You better evaluate yourself on the project you are going to use git
or Hg. Hg and git are used both by big companies. Google uses git to
host android, where as it also uses Hg to host google wave! So don't
go which company uses what, but try to evaluate... Check what is the
kind of operations your developers do often? Is it checkout, diff,
blame, also are they ready to do git gc often? What about developer
who is not interested in using cli? How do u care them for operations
they intended to do? what is the workflow? Which tools supports it to
great extent?
At the end of day, it is a developer who spends much time using tool..
Just my opinion...... you put this question in Hg list, I bet you
will get the different views....
The above is solely my opinion and I am not biased! I think so:)
On 9/27/09, 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 ...
>
> First of all, what's the matter with git and Windows, is there some
> long-term commitment to make git work on Windows as well as on Linux?
> I'm using msysgit on Windows, and personally I'm happy with it, but my
> co-workers constantly nag that Mercurial has superior portability ...
>
> Mercurial's revision number system: With git, I get an SHA1 hash for
> every commit, but it's not possible to see whether Hash1 is newer than
> Hash2, while Mecurial also adds a running number to each commit. What's
> the rationale behind this decision for git, and is it possible to
> emulate Mercurial's behavior somehow?
>
> Integration into tools: We're using Trac currently, which also has a
> nice binding to Mercurial (well, obviously easy to do as Mercurial is
> written in Python, just as Trac itself), while the git support is in
> development and looks quite alpha'ish. Do you plan to make it easier to
> integrate git with other tools by providing bindings to other languages,
> or is this a low-priority issue?
>
> So far, my key arguments are that git is more robust (more projects
> using it, larger developer base), of course git's excellent performance
> and the much better support for SVN, which is important for us as we can
> slowly migrate from SVN->Git, while hgmercurial is still in the making
> (and Python's SVN->Hg switch is for instance waiting for it).
>
> Cheers,
> Anteru
>
> --
> 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
>
--
Sent from my mobile device
Dilip
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Bruce Stephens @ 2009-09-28 11:17 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Johannes Schindelin, newsgroups, git
In-Reply-To: <94a0d4530909280401q4a451697re8954320682662f2@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
[...]
> Ok, thanks for pointing that out. I was thinking that maybe 'git
> blame' would also be slightly faster on hg, but I really don't know.
hg (and git) store binary deltas. AFAIK neither attempts to use those
to produce output for blame, diff, etc. (git's deltas may well be
slightly different from mercurial's, in that git's can be deltas with
respect to something arbitrary so even if they had a suitable line-based
format they'd be useless for diff, blame.)
Similarly for the other major systems, with the exception of (I think)
bzr and darcs. (I don't know how bzr or darcs actually work, but IIRC
they both have line-based storage that in principle might be usable in
computing blame and diff.)
[...]
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Felipe Contreras @ 2009-09-28 11:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: newsgroups, git
In-Reply-To: <alpine.DEB.1.00.0909281059180.4985@pacific.mpi-cbg.de>
On Mon, Sep 28, 2009 at 1:08 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> 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.
Ok, thanks for pointing that out. I was thinking that maybe 'git
blame' would also be slightly faster on hg, but I really don't know.
Anyway, I think for most operations git would always be faster, and
more importantly; some essential operations will be faster (checkout,
diff <committish>).
--
Felipe Contreras
^ 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
* 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
* 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: [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: 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
* 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: [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
* 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: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: 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: 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: 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
* [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: [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
* 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
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