Git development
 help / color / mirror / Atom feed
* Re: [PATCH 10/11] Add MSVC Project file
From: Johannes Schindelin @ 2009-08-17 21:11 UTC (permalink / raw)
  To: Pau Garcia i Quiles; +Cc: Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171359o33f6ca70n599bdc27be74784a@mail.gmail.com>

Hi,

On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:

> On Mon, Aug 17, 2009 at 10:56 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
> > The problem is that this will bitrot even more, as nobody will use it 
> > for gcc, Borland C++, XCode, Eclipse or anything else, except for 
> > Microsoft Visual C++.
> 
> How do you know? Also, please note I'm not talking about *adding* a 
> CMake build system, I'm talking about *replacing* the existing autotools 
> build system with a CMake build system, even if they coexist for some 
> time.

You are mistaken.  We do not require using the autotools.  I _never_ call 
"./configure" yet the Makefile magically works.  Cool, huh?

But here's a clue: you will probably _never_ succeed in getting a 
replacement of the make-based build in git.git by the maintainer.  Make is 
just too ubiquitous and well-established for that.

Having said that, a CMake-based system _in addition_ to what is 
tried-and-tested to be able to support all those different kinds of 
Microsoft Visual Studio (took me 3 attempts to write that without a 
Freudian) would be welcome, _if_ you succeed in making it compile out of 
the box on msysGit.

By out-of-the-box I mean: you send a patch that adds 
/src/cmake/release.sh, I apply the patch (after briefly scanning that it 
does not install a backdoor on a machine that is not even mine, and 
therefore will never see even a single of my passwords typed in), run it, 
it compiles installs and commits cmake and cmake works.

If that's not possible, I refuse to add another problem rather than 
solving one.

If you succeed, I will ask you to do the same for Python, as you clearly 
proved by that point that you are a magician.

Ciao,
Dscho

^ permalink raw reply

* [PATCH] GIT_SSH does not override ssh in git-svn
From: Karthik R @ 2009-08-17 21:09 UTC (permalink / raw)
  To: git



Signed-off-by: Karthik R <karthikr@fastmail.fm>
---

Setting GIT_SSH when using "git svn clone svn+ssh://..." does not 
override the
default ssh; SVN_SSH needs to be set instead. Corrected this.

Also, on Windows, SVN_SSH needs to be set with \ escaped
  e.g., "C:\\PuTTY\\plink.exe"

See http://code.google.com/p/msysgit/issues/detail?id=305

 git-svn.perl |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index b0bfb74..c932b6e 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -21,6 +21,16 @@ $Git::SVN::default_ref_id = $ENV{GIT_SVN_ID} || 
'git-svn';
 $Git::SVN::Ra::_log_window_size = 100;
 $Git::SVN::_minimize_url = 'unset';
 
+my $git_ssh_user_set = 1 if defined $ENV{GIT_SSH};
+if ($git_ssh_user_set) {
+       # If GIT_SSH is set, also set SVN_SSH...
+       $ENV{SVN_SSH} = $ENV{GIT_SSH};
+       # ... and escape \s in shell-variable on Windows
+       if ($^O eq 'MSWin32' || $^O eq 'msys') {
+               $ENV{SVN_SSH} =~ s/\\/\\\\/g;
+       }
+}
+
 $Git::SVN::Log::TZ = $ENV{TZ};
 $ENV{TZ} = 'UTC';
 $| = 1; # unbuffer STDOUT
-- 
1.5.4.3

^ permalink raw reply related

* Re: [PATCH 10/11] Add MSVC Project file
From: Johannes Schindelin @ 2009-08-17 21:05 UTC (permalink / raw)
  To: Pau Garcia i Quiles
  Cc: Reece Dunn, Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171354i6dd231etb576859ab8941214@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1985 bytes --]

Hi,

On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:

> On Mon, Aug 17, 2009 at 10:43 PM, Reece Dunn<msclrhd@googlemail.com> wrote:
> > 2009/8/17 Pau Garcia i Quiles <pgquiles@elpauer.org>:
> >> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
> >> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> >>
> >>> Of course, we could have a script that verifies that the .vcproj 
> >>> files contain reference the appropriate files (which it would know 
> >>> about by being called from the Makefile and being passed the file 
> >>> names), maybe even be able to edit the .vcproj file if it is missing 
> >>> some.  Should not be too hard in Perl.
> >>
> >> You'll need to special-case for Visual C++ 2010, which is different 
> >> and incompatible with previous versions. Hence my suggestion for 
> >> CMake: appropriate project files would be generated for the tool the 
> >> user chooses, be it VC++ 2005, VC++2010, gcc, Borland C++ or anything 
> >> else.
> >
> > The problem is that you'd still need the Visual Studio projects (one 
> > each for 6, 7 (2002), 7.1 (2003), 8 (2005), 9 (2008) and 10 (2010) -- 
> > yes, there'll need to be one for each version of Visual Studio) as 
> > people who use Visual Studio tend to primarily use the IDE. CMake 
> > (which Windows users will need to download & install from somewhere) 
> > will sit outside this -- unless you mean making the project files be 
> > the "Makefile project" type and simply use it to invoke CMake and host 
> > the source files to ease access to them from the IDE?
> 
> If a CMake build system is provided, you will not need a single Visual 
> Studio project, or the autotools build system, or anything else. Just 
> CMake and the CMake build system (which are a bunch of CMakeLists.txt 
> plain text files).

You are putting an undue burden on the already overloaded maintainer.

Well, let's see if you can provide a /src/cmake/release.sh that compiles 
CMake from scratch, and _then_ I'll look into CMake again.

Ciao,
Dscho

^ permalink raw reply

* Re: CMake, was Re: [PATCH 09/11] Add MSVC porting header files.
From: Pau Garcia i Quiles @ 2009-08-17 21:03 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172256560.8306@pacific.mpi-cbg.de>

> In any case, before you get CMake to compile in msysGit, I think we do not
> need to talk about getting problems solved.

At this moment I feel like developing a CMake build system for git
would be a waste of time, it would never be accepted upstream. I'm not
sure I want to spend my time in such an effort (it would easily take
2-3 days full time) and see it trashed. Sorry for being so clear, but
I tend to contribute only to projects where my help and time are
appreciated.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

^ permalink raw reply

* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Johannes Schindelin @ 2009-08-17 21:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Frank Li, git, msysgit
In-Reply-To: <7v1vnauto6.fsf@alter.siamese.dyndns.org>

Hi,

On Mon, 17 Aug 2009, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > How about this instead?
> >
> > 	Avoid declaration after instruction
> 
> It's called declaration-after-statement.

Of course.  Thank you.

> I always compile with "-Wall -Wdeclaration-after-statement -Werror" 
> (among other things; if you are interested, see "Make" script in 'todo' 
> branch for details) but this being in compat/mingw.c, obviously it is 
> outside of my coverage.

I have this in my own tree since long ago, back when you sent a mail whose 
reference I did not record, unfortunately.

Of course, msysGit was not there yet to allow me to compile my tree (and 
more importantly, pass the test suite), so I did not realize the 
violations in compat/.

Hence my intention to set the compiler flags just after merging the early 
commits of Frank's work.

Ciao,
Dscho

^ permalink raw reply

* Re: [PATCH 10/11] Add MSVC Project file
From: Pau Garcia i Quiles @ 2009-08-17 20:59 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172255140.8306@pacific.mpi-cbg.de>

On Mon, Aug 17, 2009 at 10:56 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
>
>> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
>> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>>
>> > Of course, we could have a script that verifies that the .vcproj files
>> > contain reference the appropriate files (which it would know about by
>> > being called from the Makefile and being passed the file names), maybe
>> > even be able to edit the .vcproj file if it is missing some.  Should
>> > not be too hard in Perl.
>>
>> You'll need to special-case for Visual C++ 2010, which is different
>> and incompatible with previous versions.
>
> Ah, my beloved Microsoft time tax!

Sorry, but I make a living developing cross-platform software and
porting stuff among any funny combination of Linux, Windows, gcc,
mingw, Intel C++ and Visual C++ you can think of. CMake makes my life
easier (possible!). Given that the patches we are talking about happen
to add support for Visual C++, I'd say it stepped in at the right
moment.

>> Hence my suggestion for CMake: appropriate project files would be
>> generated for the tool the user chooses, be it VC++ 2005, VC++2010, gcc,
>> Borland C++ or anything else.
>
> The problem is that this will bitrot even more, as nobody will use it for
> gcc, Borland C++, XCode, Eclipse or anything else, except for Microsoft
> Visual C++.

How do you know? Also, please note I'm not talking about *adding* a
CMake build system, I'm talking about *replacing* the existing
autotools build system with a CMake build system, even if they coexist
for some time.

What would be the point of having two build-systems, one (autotools)
useless for Visual C++, the other one (CMake) apt for every platform ?

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

^ permalink raw reply

* Re: CMake, was Re: [PATCH 09/11] Add MSVC porting header files.
From: Johannes Schindelin @ 2009-08-17 20:58 UTC (permalink / raw)
  To: Pau Garcia i Quiles; +Cc: Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171251y355a1e2bjf2d10192bc3eca2e@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1257 bytes --]

Hi,

On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:

> On Mon, Aug 17, 2009 at 9:48 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> 
> > On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
> >
> >> What about having a CMake build system, which would work on every
> >> platform (including cross-compiling), and would produce an appropriate
> >> config.h and makefiles/vcproj/Eclipse projects/XCode projects/whatever
> >> is fit for each platform? If it's OK to include such a build system
> >> upstream, I'm volunteering to implement it.
> >
> > And reap in another dependency?
> >
> > First Python, then CMake, what tomorrow?  Is it the month of adding
> > dependencies?
> 
> I'd say it's the month of getting problems solved.

What?  I beg your _pardon_?

> CMake would make git a lot easier to build on Windows, particularly with 
> Visual C++. Replace autotools with CMake and suddenly you need to 
> maintain a single build system for every platform and compiler git 
> supports/will support. That's a sound advantage to me.

Well, I heard some pretty different opinions, and they are from quite 
recently.

In any case, before you get CMake to compile in msysGit, I think we do not 
need to talk about getting problems solved.

Ciao,
Dscho

^ permalink raw reply

* Re: [PATCH 10/11] Add MSVC Project file
From: Johannes Schindelin @ 2009-08-17 20:56 UTC (permalink / raw)
  To: Pau Garcia i Quiles; +Cc: Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171317s3ef1506fpb3df11916f8a6ee9@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 983 bytes --]

Hi,

On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:

> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> 
> > Of course, we could have a script that verifies that the .vcproj files 
> > contain reference the appropriate files (which it would know about by 
> > being called from the Makefile and being passed the file names), maybe 
> > even be able to edit the .vcproj file if it is missing some.  Should 
> > not be too hard in Perl.
> 
> You'll need to special-case for Visual C++ 2010, which is different
> and incompatible with previous versions.

Ah, my beloved Microsoft time tax!

> Hence my suggestion for CMake: appropriate project files would be 
> generated for the tool the user chooses, be it VC++ 2005, VC++2010, gcc, 
> Borland C++ or anything else.

The problem is that this will bitrot even more, as nobody will use it for 
gcc, Borland C++, XCode, Eclipse or anything else, except for Microsoft 
Visual C++.

Ciao,
Dscho

^ permalink raw reply

* Re: [PATCH 10/11] Add MSVC Project file
From: Pau Garcia i Quiles @ 2009-08-17 20:54 UTC (permalink / raw)
  To: Reece Dunn
  Cc: Johannes Schindelin, Erik Faye-Lund, Paolo Bonzini, Frank Li, git,
	msysgit
In-Reply-To: <3f4fd2640908171343s6e2796a8le0455e02fd8386d9@mail.gmail.com>

On Mon, Aug 17, 2009 at 10:43 PM, Reece Dunn<msclrhd@googlemail.com> wrote:
> 2009/8/17 Pau Garcia i Quiles <pgquiles@elpauer.org>:
>> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
>> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>>
>>> Of course, we could have a script that verifies that the .vcproj files
>>> contain reference the appropriate files (which it would know about by
>>> being called from the Makefile and being passed the file names), maybe
>>> even be able to edit the .vcproj file if it is missing some.  Should not
>>> be too hard in Perl.
>>
>> You'll need to special-case for Visual C++ 2010, which is different
>> and incompatible with previous versions. Hence my suggestion for
>> CMake: appropriate project files would be generated for the tool the
>> user chooses, be it VC++ 2005, VC++2010, gcc, Borland C++ or anything
>> else.
>
> The problem is that you'd still need the Visual Studio projects (one
> each for 6, 7 (2002), 7.1 (2003), 8 (2005), 9 (2008) and 10 (2010) --
> yes, there'll need to be one for each version of Visual Studio) as
> people who use Visual Studio tend to primarily use the IDE. CMake
> (which Windows users will need to download & install from somewhere)
> will sit outside this -- unless you mean making the project files be
> the "Makefile project" type and simply use it to invoke CMake and host
> the source files to ease access to them from the IDE?

If a CMake build system is provided, you will not need a single Visual
Studio project, or the autotools build system, or anything else. Just
CMake and the CMake build system (which are a bunch of CMakeLists.txt
plain text files).

CMake takes the CMakeLists.txt file(s) as the input and generates
makefiles for gcc, vcproj files for Visual C++, makefiles for NMake,
Eclipse projects for Eclipse, XCode projects for XCode, etc.

> Also, not every posix system will have CMake installed (e.g. Linux
> From Scratch systems) and that's not including "exotic" systems like
> Solaris and the *BSDs.

CMake is available for many platforms (Linux x86-32 and x86-64, PPC,
Solaris Sparc, HP-UX, Irix, AIX PPC) as a binary from the CMake site (
http://cmake.org/cmake/resources/software.html ) and as source for the
rest.

*BSD? It is available in the ports section (and maybe as a binary,
too) in FreeBSD(
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/cmake/ ), NetBSD and
OpenBSD.

Linux from scratch? If people are brave enough to build and use LFS,
they are brave enough to build CMake (CMake is autocontained and
bootstraps itself, it only depends on a C++ compiler to build itself).

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

^ permalink raw reply

* Re: [PATCH 10/11] Add MSVC Project file
From: Johannes Schindelin @ 2009-08-17 20:54 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: Erik Faye-Lund, Frank Li, git, msysgit
In-Reply-To: <4A89B772.8060307@gnu.org>


Hi,

On Mon, 17 Aug 2009, Paolo Bonzini wrote:

> > I think the killer argument against such a script (I actually though 
> > of that myself, but decided against it for that very reason) is that 
> > the result is to be used by Microsoft Visual Studio users, who do not 
> > typically have a scripting language, and who would not want to use it 
> > anyway.
> 
> But the script could run whenever the Makefile is updated, even under 
> Unix.

But that would have to be kept in mind by the maintainer, and he could not 
test it.

Besides, IIUC you were proposing a generator, while I suggested a 
rewriter.  My idea would require much less work, as the changes to the 
original, known good, .vcproj are minimal.

So let's have a script (if anybody feels compelled enough) that we can run 
from time to time and when it updates at least one of the .vcproj file, we 
throw the result at Frank Li for testing.

Ciao,
Dscho

^ permalink raw reply

* Re: How-to checkin git hook
From: Joe D'Abbraccio @ 2009-08-17 20:46 UTC (permalink / raw)
  To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0908171327l1dd1a36n5e58828d70b18bfe@mail.gmail.com>

Thanks for the info.

How do people typically manage the hooks for their projects?  These may 
change over the life of the project and may be project version 
dependent.  Is the best way to place them into another subdir within 
your project with instructions on updating the hooks files?  Looks like 
a step that would be prone to errors though.

And how about the fact that post-checkout.sample is missing in the 
release I am using.  Is this the only one missing or are there others?

It would also be a good idea if the githooks man page explains this. 
Maybe when I better understand how hooks are best managed, I will 
provide my thoughts on the man page.

Regards,
Joe

Alex Riesen wrote:
> On Mon, Aug 17, 2009 at 22:15, Joe D'Abbraccio<dajoe13@gmail.com> wrote:
>> I have not been able to find out how to commit and push a hook to my git
>> server archive for everyone's benefit. The githooks man page does not
>> describe this and I have not turned up any fruitful google searches on the
>> topic.
>>
>> I am trying to add a post-checkout hook. I also noticed that the
>> post-checkout sample does not exist when I init a new archive. Is this a
>> bug?  I am running git version 1.6.0.2.
> 
> No. It didn't occurred to anyone before to push repository's configuration
> and service files (the hooks). Everybody just copied them into the server
> repositories or edited them in place.
> 
> If the server is a public place like github, it is not very likely they allow
> you to run anything you like on their servers (and hooks are programs).
> 

^ permalink raw reply

* Re: [PATCH 10/11] Add MSVC Project file
From: Reece Dunn @ 2009-08-17 20:43 UTC (permalink / raw)
  To: Pau Garcia i Quiles
  Cc: Johannes Schindelin, Erik Faye-Lund, Paolo Bonzini, Frank Li, git,
	msysgit
In-Reply-To: <3af572ac0908171317s3ef1506fpb3df11916f8a6ee9@mail.gmail.com>

2009/8/17 Pau Garcia i Quiles <pgquiles@elpauer.org>:
> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
>> Of course, we could have a script that verifies that the .vcproj files
>> contain reference the appropriate files (which it would know about by
>> being called from the Makefile and being passed the file names), maybe
>> even be able to edit the .vcproj file if it is missing some.  Should not
>> be too hard in Perl.
>
> You'll need to special-case for Visual C++ 2010, which is different
> and incompatible with previous versions. Hence my suggestion for
> CMake: appropriate project files would be generated for the tool the
> user chooses, be it VC++ 2005, VC++2010, gcc, Borland C++ or anything
> else.

The problem is that you'd still need the Visual Studio projects (one
each for 6, 7 (2002), 7.1 (2003), 8 (2005), 9 (2008) and 10 (2010) --
yes, there'll need to be one for each version of Visual Studio) as
people who use Visual Studio tend to primarily use the IDE. CMake
(which Windows users will need to download & install from somewhere)
will sit outside this -- unless you mean making the project files be
the "Makefile project" type and simply use it to invoke CMake and host
the source files to ease access to them from the IDE?

Also, not every posix system will have CMake installed (e.g. Linux
From Scratch systems) and that's not including "exotic" systems like
Solaris and the *BSDs.

- Reece

^ permalink raw reply

* [PATCH] filter-branch: add an example how to add ACKs to a range of commits
From: Johannes Schindelin @ 2009-08-17 20:38 UTC (permalink / raw)
  To: git, gitster
In-Reply-To: <cover.1250541493u.git.johannes.schindelin@gmx.de>

When you have to add certain lines like ACKs (or for that matter,
Signed-off-by:s) to a range of commits starting with HEAD, you might
be tempted to use 'git rebase -i -10', but that is a waste of your
time.

It is better to use 'git filter-branch' with an appropriate message
filter, and this commit adds an example how to do so to
filter-branch's man page.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/git-filter-branch.txt |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index ab527b5..32ea856 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -305,6 +305,16 @@ range in addition to the new branch name.  The new branch name will
 point to the top-most revision that a 'git-rev-list' of this range
 will print.
 
+If you need to add 'Acked-by' lines to, say, the last 10 commits (none
+of which is a merge), use this command:
+
+--------------------------------------------------------
+git filter-branch --msg-filter '
+	cat &&
+	echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>"
+' HEAD~10..HEAD
+--------------------------------------------------------
+
 *NOTE* the changes introduced by the commits, and which are not reverted
 by subsequent commits, will still be in the rewritten branch. If you want
 to throw out _changes_ together with the commits, you should use the
-- 
1.6.4.313.g3d9e3

^ permalink raw reply related

* Re: How-to checkin git hook
From: Alex Riesen @ 2009-08-17 20:27 UTC (permalink / raw)
  To: Joe D'Abbraccio; +Cc: git
In-Reply-To: <4A89BA5D.1000608@gmail.com>

On Mon, Aug 17, 2009 at 22:15, Joe D'Abbraccio<dajoe13@gmail.com> wrote:
> I have not been able to find out how to commit and push a hook to my git
> server archive for everyone's benefit. The githooks man page does not
> describe this and I have not turned up any fruitful google searches on the
> topic.
>
> I am trying to add a post-checkout hook. I also noticed that the
> post-checkout sample does not exist when I init a new archive. Is this a
> bug?  I am running git version 1.6.0.2.

No. It didn't occurred to anyone before to push repository's configuration
and service files (the hooks). Everybody just copied them into the server
repositories or edited them in place.

If the server is a public place like github, it is not very likely they allow
you to run anything you like on their servers (and hooks are programs).

^ permalink raw reply

* Re: How-to checkin git hook
From: Erik Faye-Lund @ 2009-08-17 20:26 UTC (permalink / raw)
  To: Joe D'Abbraccio; +Cc: git
In-Reply-To: <4A89BA5D.1000608@gmail.com>

On Mon, Aug 17, 2009 at 10:15 PM, Joe D'Abbraccio<dajoe13@gmail.com> wrote:
> I am trying to add a post-checkout hook. I also noticed that the
> post-checkout sample does not exist when I init a new archive. Is this a
> bug?

No, it's security. Hooks are executable files and shouldn't blindly be
copied around for security reasons.

-- 
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656

^ permalink raw reply

* Re: [PATCH 10/11] Add MSVC Project file
From: Pau Garcia i Quiles @ 2009-08-17 20:17 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172149480.8306@pacific.mpi-cbg.de>

On Mon, Aug 17, 2009 at 9:53 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:

> Of course, we could have a script that verifies that the .vcproj files
> contain reference the appropriate files (which it would know about by
> being called from the Makefile and being passed the file names), maybe
> even be able to edit the .vcproj file if it is missing some.  Should not
> be too hard in Perl.

You'll need to special-case for Visual C++ 2010, which is different
and incompatible with previous versions. Hence my suggestion for
CMake: appropriate project files would be generated for the tool the
user chooses, be it VC++ 2005, VC++2010, gcc, Borland C++ or anything
else.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

^ permalink raw reply

* How-to checkin git hook
From: Joe D'Abbraccio @ 2009-08-17 20:15 UTC (permalink / raw)
  To: git

I have not been able to find out how to commit and push a hook to my git 
server archive for everyone's benefit. The githooks man page does not 
describe this and I have not turned up any fruitful google searches on 
the topic.

I am trying to add a post-checkout hook. I also noticed that the 
post-checkout sample does not exist when I init a new archive. Is this a 
bug?  I am running git version 1.6.0.2.


Regards,
Joe

^ permalink raw reply

* Re: [msysGit] Re: [PATCH 09/11] Add MSVC porting header files.
From: Johannes Sixt @ 2009-08-17 20:07 UTC (permalink / raw)
  To: Pau Garcia i Quiles; +Cc: msysgit, Johannes Schindelin, Frank Li, git
In-Reply-To: <3af572ac0908171231n30864c85ud67454a03ca08fbe@mail.gmail.com>

On Montag, 17. August 2009, Pau Garcia i Quiles wrote:
> What about having a CMake build system, ...

No, thank you. I have to use it for the little bit of KDE development that I 
do, and it is a horror. With autotools I at least was able to reuse my shell 
programming skills, but cmake is an entirely new language, and an absolutely 
horrible one (IMHO, of course).

-- Hannes

^ permalink raw reply

* Re: [PATCH 10/11] Add MSVC Project file
From: Paolo Bonzini @ 2009-08-17 20:02 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Erik Faye-Lund, Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172149480.8306@pacific.mpi-cbg.de>


> I think the killer argument against such a script (I actually though of 
> that myself, but decided against it for that very reason) is that the 
> result is to be used by Microsoft Visual Studio users, who do not 
> typically have a scripting language, and who would not want to use it 
> anyway.

But the script could run whenever the Makefile is updated, even under
Unix.  Of course, there are chances of bitrotting, but it cannot be
worse than having failures every time a builtin is added or otherwise a
file is added.

The main problem I see with the script is that the output would
naturally be a .gitignore-d file, but it will not be for the reason you
mention.

> Of course, we could have a script that verifies that the .vcproj files 
> contain reference the appropriate files (which it would know about by 
> being called from the Makefile and being passed the file names), maybe 
> even be able to edit the .vcproj file if it is missing some.  Should not 
> be too hard in Perl.

Yes, it's not very far from what I had in mind.

Paolo

^ permalink raw reply

* Re: CMake, was Re: [PATCH 09/11] Add MSVC porting header files.
From: Pau Garcia i Quiles @ 2009-08-17 19:54 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171251y355a1e2bjf2d10192bc3eca2e@mail.gmail.com>

On Mon, Aug 17, 2009 at 9:51 PM, Pau Garcia i
Quiles<pgquiles@elpauer.org> wrote:
> On Mon, Aug 17, 2009 at 9:48 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
>> On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
>>
>>> What about having a CMake build system, which would work on every
>>> platform (including cross-compiling), and would produce an appropriate
>>> config.h and makefiles/vcproj/Eclipse projects/XCode projects/whatever
>>> is fit for each platform? If it's OK to include such a build system
>>> upstream, I'm volunteering to implement it.
>>
>> And reap in another dependency?
>>
>> First Python, then CMake, what tomorrow?  Is it the month of adding
>> dependencies?
>
> I'd say it's the month of getting problems solved.
>
> CMake would make git a lot easier to build on Windows, particularly
> with Visual C++. Replace autotools with CMake and suddenly you need to
> maintain a single build system for every platform and compiler git
> supports/will support. That's a sound advantage to me.

I forgot to say CMake would be a build-dependency, not a runtime
dependency, in case anyone is wondering.

More info about CMake:
http://www.cmake.org

Tutorial:
http://www.elpauer.org/stuff/learning_cmake.pdf

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

^ permalink raw reply

* Re: [PATCH 10/11] Add MSVC Project file
From: Johannes Schindelin @ 2009-08-17 19:53 UTC (permalink / raw)
  To: Erik Faye-Lund; +Cc: Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <40aa078e0908171040g5718a809o88b093fe5a4a0e28@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1221 bytes --]

Hi,

On Mon, 17 Aug 2009, Erik Faye-Lund wrote:

> On Mon, Aug 17, 2009 at 7:34 PM, Paolo Bonzini<bonzini@gnu.org> wrote:
> > Also, a cleaner XML without verbosities like
> >
> > +                       <Tool
> > +                               Name="VCMIDLTool"
> > +                       />
> >
> > would make the patch easier to review.
> 
> ...but will it make it more annoying to maintain in the long run? It 
> might be painful to work with a mixture of hand-written and 
> msdev-written XML. Of course, if we get some scripts in place to 
> generate the vcproj-files this might not be a problem...

I think the killer argument against such a script (I actually though of 
that myself, but decided against it for that very reason) is that the 
result is to be used by Microsoft Visual Studio users, who do not 
typically have a scripting language, and who would not want to use it 
anyway.

Of course, we could have a script that verifies that the .vcproj files 
contain reference the appropriate files (which it would know about by 
being called from the Makefile and being passed the file names), maybe 
even be able to edit the .vcproj file if it is missing some.  Should not 
be too hard in Perl.

Ciao,
Dscho

^ permalink raw reply

* Re: CMake, was Re: [PATCH 09/11] Add MSVC porting header files.
From: Pau Garcia i Quiles @ 2009-08-17 19:51 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172147240.8306@pacific.mpi-cbg.de>

On Mon, Aug 17, 2009 at 9:48 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:

> On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
>
>> What about having a CMake build system, which would work on every
>> platform (including cross-compiling), and would produce an appropriate
>> config.h and makefiles/vcproj/Eclipse projects/XCode projects/whatever
>> is fit for each platform? If it's OK to include such a build system
>> upstream, I'm volunteering to implement it.
>
> And reap in another dependency?
>
> First Python, then CMake, what tomorrow?  Is it the month of adding
> dependencies?

I'd say it's the month of getting problems solved.

CMake would make git a lot easier to build on Windows, particularly
with Visual C++. Replace autotools with CMake and suddenly you need to
maintain a single build system for every platform and compiler git
supports/will support. That's a sound advantage to me.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

^ permalink raw reply

* Re: [PATCH 2/2 (v2)] reset: make the output more user-friendly.
From: Junio C Hamano @ 2009-08-17 19:50 UTC (permalink / raw)
  To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqljlipcs6.fsf@bauges.imag.fr>

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>>>
>>>>  cat > expect << EOF
>>>> -file2: locally modified
>>>> +Unstaged changes after reset:
>>>> +M	file2
>>>
>>> It simply feels backwards when plumbing output says something in human
>>> language (e.g. "needs update") while Porcelain output spits out a cryptic
>>> M or U.  If the goal is human-readability and user-friendliness,
>>
>> The goal here is just consistency.
>>
>> And I do consider 'git diff --name-status' as porcelain.

Ok.

^ permalink raw reply

* Re: [PATCH] git-config: Parse config files leniently
From: Junio C Hamano @ 2009-08-17 19:49 UTC (permalink / raw)
  To: Michael J Gruber; +Cc: git, David Reitter, Jakub Narebski
In-Reply-To: <4A89A5B8.9040405@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:


> Junio C Hamano venit, vidit, dixit 14.08.2009 21:52:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>> ...
>> But I may be being overly cautious.
>
> My first version had the lenient mode for "git config -e" only, which
> required a new global int (or, alternatively, changing all callers).

Without looking at the actual patch, that "single global that is only used
by builtin_config() when using -e" sounds safer.

But still I think I may be being overly cautious.

>> By the way, why did you have to change s/echo/printf/?  Can't you give two
>> lines in a single argument without "\n" escape?
>
> Because "printf" is more portable then "echo -e". At least I hope so ;)
> [ One could use a "here document", of course. Is that preferable? ]

What I meant was to give literally two lines, like this:

    check section.key 'warning: bad config file line 2 in .git/config
warning: bad config file line 2 in .git/config'

I do not see a need for a here-doc.

The rest is tangent you can ignore.

>>> Instead, issue a warning only and treat the rest of the line as a
>>> comment (ignore it). This benefits not only git config -e users.
>> 
>> ... a broken sentence in the middle?  I would have expected the "not only"
>> followed by "but also"; the question is "but also what?"
>
> I don't see any broken sentence here. "Benefit" is a verb as well as a noun.

Yes, and I think you read me correctly.

s/broken/chopped in the middle, missing 'but also X'/;

and you just explained that you meant "everyone else" by that X in the
missing part of the sentence.

^ permalink raw reply

* CMake, was Re: [PATCH 09/11] Add MSVC porting header files.
From: Johannes Schindelin @ 2009-08-17 19:48 UTC (permalink / raw)
  To: Pau Garcia i Quiles; +Cc: Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171231n30864c85ud67454a03ca08fbe@mail.gmail.com>


Hi,

On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:

> What about having a CMake build system, which would work on every
> platform (including cross-compiling), and would produce an appropriate
> config.h and makefiles/vcproj/Eclipse projects/XCode projects/whatever
> is fit for each platform? If it's OK to include such a build system
> upstream, I'm volunteering to implement it.

And reap in another dependency?

First Python, then CMake, what tomorrow?  Is it the month of adding 
dependencies?

Ciao,
Dscho

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox