* [PATCH] perl/Makefile.PL: detect MakeMaker versions incompatible with DESTDIR
From: Brandon Casey @ 2009-09-24 18:02 UTC (permalink / raw)
To: gitster; +Cc: git, c, Brandon Casey
In-Reply-To: <7vk4zrt035.fsf@alter.siamese.dyndns.org>
From: Brandon Casey <drafnel@gmail.com>
It appears that ExtUtils::MakeMaker versions older than 6.11 do not
implement the DESTDIR mechanism. So add a test to the generated perl.mak
to detect when DESTDIR is used along with a too old ExtUtils::MakeMaker and
abort with a message suggesting the use of NO_PERL_MAKEMAKER.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Junio C Hamano wrote:
> Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
>
>> Possibly it is related to the version of MakeMaker? I am using version
>> 6.17 (Revision: 1.133) along with Perl 5.8.4 on Solaris 10 x86. The
>> MakeMaker version should be in the header at the top of the perl.mak
>> file.
>
> I think that is it. DESTDIR support in MakeMaker seems to be lacking in
> medieval versions of Perl. It appears that it started being usable at
> around its 6.11 (and 6.17 you have is fine).
>
> http://kobesearch.cpan.org/htdocs/ExtUtils-MakeMaker/Changes.html
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6131#c7
How about something like this?
Seems to work correctly for me on IRIX 6.5 and Solaris 7 with
ExtUtils::MakeMaker 6.03.
-brandon
perl/Makefile.PL | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 320253e..8974015 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -5,6 +5,14 @@ sub MY::postamble {
instlibdir:
@echo '$(INSTALLSITELIB)'
+ifneq (,$(DESTDIR))
+ifeq (1,$(shell expr '$(MM_VERSION)' '<' 6.11))
+$(error ExtUtils::MakeMaker version "$(MM_VERSION)" is older than 6.11 and so \
+ is likely incompatible with the DESTDIR mechanism. Try setting \
+ NO_PERL_MAKEMAKER=1 instead)
+endif
+endif
+
MAKE_FRAG
}
--
1.6.4.3
^ permalink raw reply related
* Re: How does gitosis know who the key belongs to
From: Heiko Voigt @ 2009-09-24 17:26 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0909240751k3a799750h121935a79439b389@mail.gmail.com>
On Thu, Sep 24, 2009 at 03:51:44PM +0100, Howard Miller wrote:
> Gitosis obviously uses keypairs but the config file addresses the user
> by name/host. How does gitosis connect the two together? Is it any
> more complicated than the user detail at the end of the public key?
Not much different. It uses the command feature of the authorized_keys
file of ssh to limit access to the 'gitosis-serve' command which is
given the username from the gitosis.conf as argument. gitosis-server
then takes care of the access control.
> The second part of my question then is is it possible to use the same
> private key on more than one host?
Yes definitely. It identifies the user not the host. Although you can
use differenty keys if you want.
cheers Heiko
^ permalink raw reply
* Re: [RFC] 'git cat-file' needs a better design on its option interface
From: Linus Torvalds @ 2009-09-24 17:23 UTC (permalink / raw)
To: Li Hong; +Cc: Junio C Hamano, git
In-Reply-To: <3a3680030909240804w1399ed7fhd6367300544f34f@mail.gmail.com>
On Thu, 24 Sep 2009, Li Hong wrote:
>
> When using 'git cat-file' recently, I find its option interface is somewhat
> inconvenient or mistakenly-designed.
You likely shouldn't use 'cat-file' at all. Have you looked at 'git show'?
That's the command meant for human beings.
'git cat-file' is really really low-level plumbing. Humans should
generally never use it. It's one of the original git commands (it was
literally in the original git commit), and it does some really low-level
stuff that is good for scripting but not for any normal use.
Linus
^ permalink raw reply
* [PATCH] git-gui: fix use of uninitialized variable
From: Jens Lehmann @ 2009-09-24 16:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
This fixes a bug introduced by the "display summary when showing diff of a
submodule" patch. It lead to a "no such variable" error when opening the
diff context menu while no diff was shown.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
git-gui/git-gui.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 3c0ce26..f727111 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -1132,6 +1132,7 @@ set current_branch {}
set is_detached 0
set current_diff_path {}
set is_3way_diff 0
+set is_submodule_diff 0
set is_conflict_diff 0
set selected_commit_type new
set diff_empty_count 0
--
1.6.5.rc2.5.gbbf1
^ permalink raw reply related
* Re: [RFC] 'git cat-file' needs a better design on its option interface
From: Jeff King @ 2009-09-24 16:48 UTC (permalink / raw)
To: Li Hong; +Cc: Junio C Hamano, git
In-Reply-To: <3a3680030909240804w1399ed7fhd6367300544f34f@mail.gmail.com>
On Thu, Sep 24, 2009 at 11:04:31PM +0800, Li Hong wrote:
> When using 'git cat-file' recently, I find its option interface is somewhat
> inconvenient or mistakenly-designed.
Yes, the current interface has grown over time and kind of sucks. I
agree with all of your complaints.
That being said, the reason it has grown in that way is that as a
plumbing command, cat-file must retain backwards compatibility so as not
to break existing scripts which make use of it. And it is not enough to
look through git.git and fix all of our scripts; the interface to
cat-file is a public one, and we must take care not to break other
people's custom scripts.
I'm not quite sure where your complaints are coming from. Do you want:
1. Something more sane to type in your terminal for everyday use? Then
you probably want to use (or invent) some sort of user-facing
porcelain that does a similar thing. This is mostly covered by "git
show" these days, but if there is something lacking, proposals
describing your use case would be welcome.
2. To script around cat-file, but there is some action you want to do
that is missing from the interface? In that case, can you describe
your use case in more detail, and exactly what addition you want to
make to the cat-file interface to accomodate it?
3. To just clean up cruft from the interface for your scripts? I am
somewhat sympathetic to wanting a nicer interface. But keep in
mind that we have to keep the old interface around to support
historical scripts. So while your new interface may be more
flexible and less complex, you have to consider whether having
_both_ interfaces will actually be less complex in the long run.
-Peff
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Eric Raible @ 2009-09-24 16:45 UTC (permalink / raw)
To: git
In-Reply-To: <5b5e291e0909240225q49a202abk7cf1a0c8f715ad5f@mail.gmail.com>
Deon George <deon.george <at> gmail.com> writes:
> > Third, if the above isn't what you want, then you can manually
> > intermingle working directories of different git repositories
> > (probably requiring decouplig of bare git repository (git-dir)
> > from working area (work-tree)).
>
> Ahh, now this sounds like it might be what I want to do - I think I'll
> explore this. I can see that it would provide file level autonomy
> only, but as a starting point I think it will help heaps...
Proof of concept:
export GIT_WORK_TREE=.
git --git-dir=.git1 init
git --git-dir=.git1 add view1-file
git --git-dir=.git1 commit -m"view1 initial"
git --git-dir=.git2 init
git --git-dir=.git2 add view1-file
git --git-dir=.git2 commit -m"view2 initial"
git --git-dir=.git1 log
git --git-dir=.git2 log
^ permalink raw reply
* Re: Per-remote tracking branch
From: Matthieu Moy @ 2009-09-24 16:00 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20090924113537.GA14113@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>> Setup "foo" so that it fetches "master" only, i.e. have
>> remote.foo.fetch = refs/heads/master:refs/remotes/foo/master
>>
>> You get that setup with: git remote add -t master foo git://...
>>
>> Then there's only one possible choice for "git pull", and it will take
>> that.
>
> Ah, crap, spoke too soon. That works only when branch.<name>.merge is
> not set. Though that's not that much of a problem. When your "primary"
> remote (the one set for branch.<name>.remote) also fetches just a single
> branch, "git pull" will still work, even if branch.<name>.merge is not
> set.
Yes, that's it. Thanks for your anwser, it works.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [RFC] 'git cat-file' needs a better design on its option interface
From: Li Hong @ 2009-09-24 15:04 UTC (permalink / raw)
To: Junio C Hamano, git
Hi All,
When using 'git cat-file' recently, I find its option interface is somewhat
inconvenient or mistakenly-designed.
1. There is no default action. You have to use -p or <type> option,
even for a simple look at the content of an object. It is better if
we can provide a default action just like 'cat' does.
2. Can't control the output. Several output options can't be used at
the same time. Can't control what to output and how to output. I
suggest here we use a simple format string to let the human being
and other batch scripts happy.
3. Batch mode is handled seperately and differently.
4. <type> option has a mix meaning (raw print and object dereference)
and is also inconsistent with -x style option.
* for raw print, an format char such as 'r' should be a good choice.
* for dereference, should use the uniform rev-naming. (e.g.
v0.99.8^{commit})
So I propose to amend the interface as follow:
git cat-file [-b] [-f <fmt>] [-e] <args> ...
-b read more objects from stdin
-f provide a output format string
-e silent, exit with zero when there's no error
the default action is to pretty-print the content when there is no
other options except -b.
A format string example can be formed as follow (this needs more discuss):
"blabla %t\s%s\t%h\n%p\n%r\n\n"
%t: type
%s: size
%h: sha1
%p: pretty-print
%r: raw-print
However, this change will give a heavy impact on many documents and scripts
depending on this command. There are 233 references in source code according
to a trivial count 'grep -r "cat-file" * | wc -l', not to mention many
private usage of this command.
So this is just a RFC. If I can get a very positive feedback from the
community, I may start to do the real code change.
Any ideas?
- Li Hong
^ permalink raw reply
* How does gitosis know who the key belongs to
From: Howard Miller @ 2009-09-24 14:51 UTC (permalink / raw)
To: git
Hi,
This is probably another one of my stupid questions.
Gitosis obviously uses keypairs but the config file addresses the user
by name/host. How does gitosis connect the two together? Is it any
more complicated than the user detail at the end of the public key?
The second part of my question then is is it possible to use the same
private key on more than one host?
Cheers,
Howard
^ permalink raw reply
* How does gitosis know who the key belongs to
From: Howard Miller @ 2009-09-24 14:49 UTC (permalink / raw)
To: git
Hi,
This is probably another one of my stupid questions.
Gitosis obviously uses keypairs but the config file addresses the user
by name/host. How does gitosis connect the two together? Is it any
more complicated than the user detail at the end of the public key?
The second part of my question then is is it possible to use the same
private key on more than one host?
Cheers,
Howard
^ permalink raw reply
* [PATCH 2/2] Make just opening the generated MSVC solution file not modify it
From: Sebastian Schuberth @ 2009-09-24 14:42 UTC (permalink / raw)
To: git; +Cc: mstormo
From 9a0d743e227872189b17afb0b5c69b15422a0eef Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Thu, 24 Sep 2009 16:26:59 +0200
Subject: [PATCH 2/2] Make just opening the generated MSVC solution file not modify it
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>
---
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.4.msysgit.0
^ permalink raw reply related
* [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Sebastian Schuberth @ 2009-09-24 14:40 UTC (permalink / raw)
To: git; +Cc: mstormo
From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Thu, 24 Sep 2009 15:52:25 +0200
Subject: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
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>
---
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.4.msysgit.0
^ permalink raw reply related
* [PATCH 2/2] Make just opening the generated MSVC solution file not modify it
From: Sebastian Schuberth @ 2009-09-24 14:42 UTC (permalink / raw)
To: git; +Cc: mstormo
From 9a0d743e227872189b17afb0b5c69b15422a0eef Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Thu, 24 Sep 2009 16:26:59 +0200
Subject: [PATCH 2/2] Make just opening the generated MSVC solution file not modify it
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>
---
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.4.msysgit.0
^ permalink raw reply related
* [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Sebastian Schuberth @ 2009-09-24 14:40 UTC (permalink / raw)
To: git; +Cc: mstormo
From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Thu, 24 Sep 2009 15:52:25 +0200
Subject: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
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>
---
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.4.msysgit.0
^ permalink raw reply related
* Re: 'git am' doubt
From: Thiago Farina @ 2009-09-24 14:09 UTC (permalink / raw)
To: David Aguilar; +Cc: Git Mailing List
In-Reply-To: <20090923235433.GB80337@gmail.com>
On Wed, Sep 23, 2009 at 8:54 PM, David Aguilar <davvid@gmail.com> wrote:
> On Wed, Sep 23, 2009 at 07:20:53PM -0300, Thiago Farina wrote:
>> Hi,
>>
>> I'm trying to apply a patch from the mailing list using 'git am'.
>>
>> What I'm doing is:
>>
>> - In gmail:
>> - Save original, then I copied the content to a text editor.
>> - In text editor:
>> - Remove the first empty line.
>> - Save the file in the same directory where I have the git source.
>> - In git directory:
>> - $ git am -s ./filename.mbox
>>
>> Of course I'm doing something wrong here, but I don't know what.
>> The error is:
>> cat: /home/tfarina/git/.git/rebase-apply/next: No such file or directory
>> previous rebase directory /home/tfarina/git/.git/rebase-apply still
>> exists but mbox given.
>
>
> Perhaps you tried this previously and 'git am' failed?
> In which case, run 'git am --abort'.
I didn't try before.
>
>
> Now.. I've _never_ had luck saving patches out of gmail.
> But, I've had good luck with its imap interface.
> I use mutt, save emails to an mbox file, and use 'git am'
> on them. This has worked great for me.
Yeah, I tried with Evolution, and it worked for me, so the problem was
with Gmail.
>
> For sending emails to the list, I use msmtp and a
> ~/.gitconfig setting:
>
>
> [sendemail]
> smtpserver = /usr/bin/msmtp
>
>
> Then it's simply 'git send-email <patch-file>'.
>
>
> Here's a random page explaining how to use mutt with gmail.
> http://shreevatsa.wordpress.com/2007/07/31/using-gmail-with-mutt-the-minimal-way/
>
> I can send you my .muttrc if that helps.
I'm using send-email to send my patches too. If you could, send me
your .muttrc, I will appreciate, may be I can try to use it instead of
Evolution.
Thanks for your help. ;)
^ permalink raw reply
* [PATCHv2] bash: teach 'git checkout' options
From: SZEDER Gábor @ 2009-09-24 12:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, SZEDER Gábor
In-Reply-To: <20090922152846.GQ14660@spearce.org>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8c268a1..a08e471 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -809,7 +809,21 @@ _git_checkout ()
{
__git_has_doubledash && return
- __gitcomp "$(__git_refs)"
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --conflict=*)
+ __gitcomp "diff3 merge" "" "${cur##--conflict=}"
+ ;;
+ --*)
+ __gitcomp "
+ --quiet --ours --theirs --track --no-track --merge
+ --conflict= --patch
+ "
+ ;;
+ *)
+ __gitcomp "$(__git_refs)"
+ ;;
+ esac
}
_git_cherry ()
--
1.6.5.rc2.85.gd02ad
^ permalink raw reply related
* RE: [JGIT PATCH 7/9] removing eclipse project files
From: Mark Struberg @ 2009-09-24 11:50 UTC (permalink / raw)
To: MatthiasSohn; +Cc: git@vger.kernel.org, spearce@spearce.org
In-Reply-To: <C89280B882467443A695734861B942B296767534@DEWDFECCR09.wdf.sap.corp>
Hi Matthias!
the answer is a clear yes and no - a 'jein' for german speaking people like you ;)
yes: we have the same settings for the compiler as used before: jdk 1.5 for source and target. This is exactly what has been taken in the ant build which was used prior to maven.
Please note that the settings in org.eclipse.jdt.core.prefs never had (and must not have) any impact on the created jar!
and no: currently the very file you mentioned contains a lot more stuff. In fact most of this are only editor settings, preferred formattings etc which has nothing to do with the build per se. Eclipse has the ability to import/export all those settings in a XML file which is version independent. We should go this way and also supply similar setting-files for Idea and NetBeans. But forcing those settings via an internal Eclipse plugin config file is imho bad practice.
LieGrue,
strub
--- On Thu, 9/24/09, Sohn, Matthias <matthias.sohn@sap.com> wrote:
> From: Sohn, Matthias <matthias.sohn@sap.com>
> Subject: RE: [JGIT PATCH 7/9] removing eclipse project files
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "git@vger.kernel.org" <git@vger.kernel.org>, "spearce@spearce.org" <spearce@spearce.org>
> Date: Thursday, September 24, 2009, 1:24 PM
> Can Maven control compiler settings
> on the same level as we do currently with
> .settings/org.eclipse.jdt.core.prefs ?
>
^ permalink raw reply
* Re: Per-remote tracking branch
From: Björn Steinbrink @ 2009-09-24 11:35 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <20090924112550.GA6540@atjola.homenet>
On 2009.09.24 13:25:50 +0200, Björn Steinbrink wrote:
> On 2009.09.15 17:29:58 +0200, Matthieu Moy wrote:
> > At the moment, I can configure a tracking branch to let me just type
> >
> > $ git pull
> >
> > when I want to say
> >
> > $ git pull origin master
> >
> > Now, assume I have another remote "foo", I'd like to be able to just
> > say
> >
> > $ git pull foo
> >
> > and put something in my .git/config so that Git knows I mean
> >
> > $ git pull foo master
> >
> > Is there a simple way to do that?
>
> Setup "foo" so that it fetches "master" only, i.e. have
> remote.foo.fetch = refs/heads/master:refs/remotes/foo/master
>
> You get that setup with: git remote add -t master foo git://...
>
> Then there's only one possible choice for "git pull", and it will take
> that.
Ah, crap, spoke too soon. That works only when branch.<name>.merge is
not set. Though that's not that much of a problem. When your "primary"
remote (the one set for branch.<name>.remote) also fetches just a single
branch, "git pull" will still work, even if branch.<name>.merge is not
set.
Björn
^ permalink raw reply
* Re: Per-remote tracking branch
From: Björn Steinbrink @ 2009-09-24 11:25 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq4or48bux.fsf@bauges.imag.fr>
On 2009.09.15 17:29:58 +0200, Matthieu Moy wrote:
> Hi,
>
> Is there a way, with Git, to specify a tracking branch on a per-remote
> basis?
>
> At the moment, I can configure a tracking branch to let me just type
>
> $ git pull
>
> when I want to say
>
> $ git pull origin master
>
> Now, assume I have another remote "foo", I'd like to be able to just
> say
>
> $ git pull foo
>
> and put something in my .git/config so that Git knows I mean
>
> $ git pull foo master
>
> Is there a simple way to do that?
Setup "foo" so that it fetches "master" only, i.e. have
remote.foo.fetch = refs/heads/master:refs/remotes/foo/master
You get that setup with: git remote add -t master foo git://...
Then there's only one possible choice for "git pull", and it will take
that.
Björn
^ permalink raw reply
* RE: [JGIT PATCH 7/9] removing eclipse project files
From: Sohn, Matthias @ 2009-09-24 11:24 UTC (permalink / raw)
To: Mark Struberg; +Cc: git@vger.kernel.org, spearce@spearce.org
In-Reply-To: <1253740570-10718-7-git-send-email-struberg@yahoo.de>
Can Maven control compiler settings on the same level as we do currently with
.settings/org.eclipse.jdt.core.prefs ?
^ permalink raw reply
* Re: Per-remote tracking branch
From: Matthieu Moy @ 2009-09-24 11:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090924062911.GC24486@coredump.intra.peff.net>
Hi, and thanks for your answer,
Jeff King <peff@peff.net> writes:
> On Tue, Sep 15, 2009 at 05:29:58PM +0200, Matthieu Moy wrote:
>
>> Is there a way, with Git, to specify a tracking branch on a per-remote
>> basis?
>
> I don't think so, and I'm not sure there is an easy way to extend the
> current configuration scheme. Adding multiple config options like this:
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> remote = alternate
> merge = refs/heads/master
I had tried this in case it would have worked ;-).
> And it feels a little backwards. When I say "git pull foo", I would find
> it equally likely to discover the pulled branch under "remote.foo" as it
> would to find it under "branch.master". Of course, in either case, you
> have to combine the context (current branch _and_ selected remote)
> to come up with the actual information.
Actually, for my particular use case (aka "almost always only one
branch per repo"), I could as well have a remote.foo.defaultBranch
regardless of the current local branch. Then, if I say "git pull foo",
it would understand it as "git pull foo <remote.foo.defaultBranch>".
If other people would be interested in such feature, say so, I may
give it a try when I have time. If I'm the only one, I guess I'll let
my fingers type the extra " master" instead ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Deon George @ 2009-09-24 9:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3bpl0c2cf.fsf@localhost.localdomain>
Jakub Narebski wrote:
> First, I assume there that you do not allow for the same file to
> belong to different repositories.
Well, no, I cant see why a file cannot belong to both repositories.
I'm sure it would be easier if a file did belong to a unique
repository, but given that GIT operates at a content layer (from what
I've read anyway), I cant see why it couldnt belong to more than one.
> you can try either submodules
> (git-submodule), or subtree (subtree merge, or third-party git-subtree
> helper).
I had a quick look at submodule - I dont think it helps me anyway,
since I want the flexibility for files to belong to many
sub-directories - not all under 1 sub directory hierarchy.
> Third, if the above isn't what you want, then you can manually
> intermingle working directories of different git repositories
> (probably requiring decouplig of bare git repository (git-dir)
> from working area (work-tree)).
Ahh, now this sounds like it might be what I want to do - I think I'll
explore this. I can see that it would provide file level autonomy
only, but as a starting point I think it will help heaps...
I'll work on it as time permits and come up with some scripts to
provide what I am after (need to learn more on the workings of GIT
first - everyday I learn a new feature :)
Thanks for your idea...
...deon
^ permalink raw reply
* Re: [PATCH] git-submodule should obey --quiet for subcommands
From: Jonathan del Strother @ 2009-09-24 9:15 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Git Mailing List
In-Reply-To: <57518fd10909240034p668f858bh17fc20715b4838c3@mail.gmail.com>
On Thu, Sep 24, 2009 at 8:34 AM, Jonathan del Strother
<maillist@steelskies.com> wrote:
> On Thu, Sep 24, 2009 at 6:31 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> Quoting Jonathan del Strother <maillist@steelskies.com>
>>
>>> No takers? Perhaps I should explain my interest in this patch : we
>>> use Capistrano to deploy our Rails app which contains a bunch of
>>> submodules. It's done over ssh, so the 'git submodule update' step
>>> during deployment spews something along the lines of :
>>>
>>> Receiving objects: 0% (0/401), 1.55 MiB | 424 KiB/s
>>> Receiving objects: 1% (4/401), 2.15 MiB | 612 KiB/s
>>> Receiving objects: 2% (8/401), 2.90 MiB | 510 KiB/s
>>> ....
>>> ..
>>
>> Does 'git clone' itself do that to you, too, or do you see these output on separate lines only when running 'git submodule clone'? I never used 'git submodule clone' but with 'git clone' these lines seem to overwrite one after another and they never bothered me. Could your terminal emulator be broken?
>>
>
> No, git clone has the same problem when run under Capistrano, but it
> obeys --quiet.
>
> That said, I always assumed that, say, 'ssh -t myhost git clone foo'
> would have the same problem (ie printing each progress update on a new
> line), but I see it works correctly. Looks like Capistrano is eating
> the \r somewhere. I still think my patch is valid, but I'll
> investigate into Capistrano some more & see if I can fix it there.
>
> Jonathan
>
... thinking about it, it's obvious why Capistrano doesn't handle the
\r properly - it's running commands in parallel on multiple machines,
and echoing any output from the commands (prefixed with the machine
name) back to the user in realtime. So it would be kinda tricky for
\r to work as expected there.
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Ferry Huberts @ 2009-09-24 8:57 UTC (permalink / raw)
To: Mark Struberg; +Cc: Ferry Huberts, git, spearce
In-Reply-To: <430881.64091.qm@web27803.mail.ukl.yahoo.com>
On Thu, September 24, 2009 10:24, Mark Struberg wrote:
> Hi again and txs 4 your comments!
ok. thanks. much enlightening :-)
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Ferry Huberts @ 2009-09-24 8:57 UTC (permalink / raw)
To: Mark Struberg; +Cc: Ferry Huberts, git, spearce
In-Reply-To: <430881.64091.qm@web27803.mail.ukl.yahoo.com>
On Thu, September 24, 2009 10:24, Mark Struberg wrote:
> Hi again and txs 4 your comments!
ok. thanks. much enlightening :-)
^ 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