GIT on MinGW problem

GIT on MinGW problem

[Aaron Gray]

Hello,

I have installed the git-1.5.1-1.mingw.exe from 
http://lilypond.org/git/binaries/mingw/.

On typing 'git' I get a message box saying :-

        The procedure entry point libiconv could not be located in the 
dynamic link library libiconv-2.dll.

I cannot seem to find libiconv-2.dll anywhere either.

Hope you can help.

Many thanks in advance,

Aaron

Re: GIT on MinGW problem

[Junio C Hamano]

"Aaron Gray" <angray@beeb.net> writes:

> Hello,
>
> I have installed the git-1.5.1-1.mingw.exe from
> http://lilypond.org/git/binaries/mingw/.
>
> On typing 'git' I get a message box saying :-
>
>        The procedure entry point libiconv could not be located in the
> dynamic link library libiconv-2.dll.
>
> I cannot seem to find libiconv-2.dll anywhere either.
>
> Hope you can help.
>
> Many thanks in advance,
>
> Aaron

Even myself (who does not have anything to do with Windows
machines) remembers seeing this exact thing in the past 12
hours:

	article.gmane.org/gmane.comp.version-control.git/46962

Please check the archive before asking.  Thanks.

Re: GIT on MinGW problem

[Aaron Gray]

>> I cannot seem to find libiconv-2.dll anywhere either.
>
> Even myself (who does not have anything to do with Windows
> machines) remembers seeing this exact thing in the past 12
> hours:
>
> article.gmane.org/gmane.comp.version-control.git/46962
>
> Please check the archive before asking.  Thanks.
>

Sorry.

The correct link is :-

http://sourceforge.net/project/downloading.php?group_id=23617&use_mirror=kent&filename=diffutils-2.8.7-1-dep.zip&19135304

renamed libiconv2.dll to libiconv-2.dll

Aaron 

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Aaron Gray escreveu:
> Hello,
> 
> I have installed the git-1.5.1-1.mingw.exe from
> http://lilypond.org/git/binaries/mingw/.
> 
> On typing 'git' I get a message box saying :-
> 
>        The procedure entry point libiconv could not be located in the
> dynamic link library libiconv-2.dll.
> 
> I cannot seem to find libiconv-2.dll anywhere either.

This should be fixed in 

http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe

it should also set $PATH.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Johannes Sixt]

Han-Wen Nienhuys wrote:
> 
> Aaron Gray escreveu:
> > Hello,
> >
> > I have installed the git-1.5.1-1.mingw.exe from
> > http://lilypond.org/git/binaries/mingw/.
> >
> > On typing 'git' I get a message box saying :-
> >
> >        The procedure entry point libiconv could not be located in the
> > dynamic link library libiconv-2.dll.
> >
> > I cannot seem to find libiconv-2.dll anywhere either.
> 
> This should be fixed in
> 
> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe
> 
> it should also set $PATH.

I gave this some more testing and it turns out to be a well working
toolset. Thank you very much!

There were still some issues remaining. These are the ones that should
be fixable easily:

* git version reports just:

	git version -dirty

Since git-gui parses the output of git version, but does not expect it
to be of this format, and fails with an error message that it cannot
parse the version.

* git without an correct git subcommand should list 20 or so commands,
but it doesn't. The list is just empty.

* I personally think that the files should go into

	$PROGRAMFILES/Git/{bin,share,lib}
instead of
	$PROGRAMFILES/Git/usr/{bin,share,lib}

The more difficult to solve problems are:

* git-gui and gitk don't work out of the box because they have the path
to wish hardcoded. They can't be started from CMD at all. I have written
wrappers gitk.cmd and git-gui.cmd with these 2 lines:

@echo off
start wish84 D:/MSYS/1.0/git/bin/gitk %*

But as you can see, the path is still hard-coded (but it is good enough
for me for the moment).

* perl scripts like git-remote contain a hard-coded path to the
installation directory and don't work for this reason.

-- Hannes

Re: GIT on MinGW problem

[Marco Costalba]

On 5/25/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Han-Wen Nienhuys wrote:
> >
> > Aaron Gray escreveu:
> > > Hello,
> > >
> > > I have installed the git-1.5.1-1.mingw.exe from
> > > http://lilypond.org/git/binaries/mingw/.
> > >
> > > On typing 'git' I get a message box saying :-
> > >
> > >        The procedure entry point libiconv could not be located in the
> > > dynamic link library libiconv-2.dll.
> > >
> > > I cannot seem to find libiconv-2.dll anywhere either.
> >
> > This should be fixed in
> >
> > http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe
> >
> > it should also set $PATH.
>
> I gave this some more testing and it turns out to be a well working
> toolset. Thank you very much!
>
> There were still some issues remaining. These are the ones that should
> be fixable easily:
>
> * git version reports just:
>
>         git version -dirty
>
> Since git-gui parses the output of git version, but does not expect it
> to be of this format, and fails with an error message that it cannot
> parse the version.
>

Yes, an error message at startup is shown also with qgit.

Also 'git status' seems to have some issues.


 Marco

Re: GIT on MinGW problem

[Johannes Schindelin]

Hi,

On Fri, 25 May 2007, Johannes Sixt wrote:

> * I personally think that the files should go into
> 
> 	$PROGRAMFILES/Git/{bin,share,lib}
> instead of
> 	$PROGRAMFILES/Git/usr/{bin,share,lib}

Agree. It is trivial, but it will help others. It might also be a good 
idea to have a shortcut in "$PF/Git/Git Gui.lnk" to the git gui (once it 
is working, that is).

> * git-gui and gitk don't work out of the box because they have the path
> to wish hardcoded. They can't be started from CMD at all. I have written
> wrappers gitk.cmd and git-gui.cmd with these 2 lines:
> 
> @echo off
> start wish84 D:/MSYS/1.0/git/bin/gitk %*
> 
> But as you can see, the path is still hard-coded (but it is good enough
> for me for the moment).

I'd also like to see bash, perl and wish bundled with the install (Windows 
lusers are so used to one big install package, so it is an _advantage_ to 
have a bigger download).

> * perl scripts like git-remote contain a hard-coded path to the
> installation directory and don't work for this reason.

GITPERLLIB should be set from the wrapper script, I think.

Ciao,
Dscho

Re: GIT on MinGW problem

[Johannes Sixt]

Johannes Schindelin wrote:
> On Fri, 25 May 2007, Johannes Sixt wrote:
> > * perl scripts like git-remote contain a hard-coded path to the
> > installation directory and don't work for this reason.
> 
> GITPERLLIB should be set from the wrapper script, I think.

The clean way is certainly to derive the directory from $0:

use lib $0 =~ /^(.*)([\/\\]+[^\/\\]*){2}$/ ? ("$1/lib") : ();

(although I'm not sure whether this would work during 'make test').

-- Hannes

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Johannes Schindelin escreveu:
> Hi,
> 
> On Fri, 25 May 2007, Johannes Sixt wrote:
> 
>> * I personally think that the files should go into
>>
>> 	$PROGRAMFILES/Git/{bin,share,lib}
>> instead of
>> 	$PROGRAMFILES/Git/usr/{bin,share,lib}
> 
> Agree. It is trivial, but it will help others. It might also be a good 
> idea to have a shortcut in "$PF/Git/Git Gui.lnk" to the git gui (once it 
> is working, that is).
> 
>> * git-gui and gitk don't work out of the box because they have the path
>> to wish hardcoded. They can't be started from CMD at all. I have written
>> wrappers gitk.cmd and git-gui.cmd with these 2 lines:
>>
>> @echo off
>> start wish84 D:/MSYS/1.0/git/bin/gitk %*
>>
>> But as you can see, the path is still hard-coded (but it is good enough
>> for me for the moment).
> 
> I'd also like to see bash, perl and wish bundled with the install (Windows 

Where is the info on the wish and bash port to Mingw?


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Johannes Schindelin]

Hi,

[before answering: a big thank you, Han-Wen, for doing that work. I think 
it is very valuable, especially because except Johannes Sixt, I have yet 
to encounter a person wanting "naive" Windows Git, but not hiding under 
the next rock when it comes to work on it.]

On Sat, 26 May 2007, Han-Wen Nienhuys wrote:

> Johannes Schindelin escreveu:
> > 
> > On Fri, 25 May 2007, Johannes Sixt wrote:
> > 
> >> * I personally think that the files should go into
> >>
> >> 	$PROGRAMFILES/Git/{bin,share,lib}
> >> instead of
> >> 	$PROGRAMFILES/Git/usr/{bin,share,lib}
> > 
> > Agree. It is trivial, but it will help others. It might also be a good 
> > idea to have a shortcut in "$PF/Git/Git Gui.lnk" to the git gui (once it 
> > is working, that is).
> > 
> >> * git-gui and gitk don't work out of the box because they have the path
> >> to wish hardcoded. They can't be started from CMD at all. I have written
> >> wrappers gitk.cmd and git-gui.cmd with these 2 lines:
> >>
> >> @echo off
> >> start wish84 D:/MSYS/1.0/git/bin/gitk %*
> >>
> >> But as you can see, the path is still hard-coded (but it is good enough
> >> for me for the moment).
> > 
> > I'd also like to see bash, perl and wish bundled with the install (Windows 
> 
> Where is the info on the wish and bash port to Mingw?

I recently compiled tcl and tk from scratch on MinGW. (No cross-compile.) 
Worked out of the box:

	http://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz
	http://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz

(Now, if only Python worked like that...)

There's a bash src in the Snapshot package of MinGW:

	http://prdownloads.sf.net/mingw/bash-2.05b-MSYS-src.tar.bz2?download

Ciao,
Dscoh

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Johannes Schindelin escreveu:

> I recently compiled tcl and tk from scratch on MinGW. (No cross-compile.) 
> Worked out of the box:
> 
> 	http://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz
> 	http://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz
>       

GCC barfs on:

      ((Tcl_Obj **) objv) += (async + 3);




-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Johannes Schindelin]

Hi,

On Sun, 27 May 2007, Han-Wen Nienhuys wrote:

> Johannes Schindelin escreveu:
> 
> > I recently compiled tcl and tk from scratch on MinGW. (No cross-compile.) 
> > Worked out of the box:
> > 
> > 	http://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz
> > 	http://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz
> >       
> 
> GCC barfs on:
> 
>       ((Tcl_Obj **) objv) += (async + 3);

Ah yes, I was using MinGW's own GCC, which is GCC 3.something.

It is a new "feature" of GCC 4.x to disallow constructs like these. 
(Probably because GCC people think that other people are not intelligent 
enough to understand such constructs, and therefore prohibit their use.)

Ciao,
Dscho

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Johannes Schindelin escreveu:

>>       ((Tcl_Obj **) objv) += (async + 3);
> 
> Ah yes, I was using MinGW's own GCC, which is GCC 3.something.
> 
> It is a new "feature" of GCC 4.x to disallow constructs like these. 
> (Probably because GCC people think that other people are not intelligent 
> enough to understand such constructs, and therefore prohibit their use.)

I very much doubt that. GCC uses type information to determine whether 
pointers might be aliased.  I think disallowing such constructs helps with
compiler optimization.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Nix]

On 27 May 2007, Han-Wen Nienhuys said:

> Johannes Schindelin escreveu:
>
>>>       ((Tcl_Obj **) objv) += (async + 3);
>> 
>> Ah yes, I was using MinGW's own GCC, which is GCC 3.something.
>> 
>> It is a new "feature" of GCC 4.x to disallow constructs like these. 
>> (Probably because GCC people think that other people are not intelligent 
>> enough to understand such constructs, and therefore prohibit their use.)
>
> I very much doubt that. GCC uses type information to determine whether 
> pointers might be aliased.  I think disallowing such constructs helps with
> compiler optimization.

Actually it was simply too difficult to maintain this extension over the
C and C++ parser rewrites in the early 4.x timeline. (Also, IIRC, it had
some *nasty* ambiguities, especially in C++.)

-- 
`On a scale of one to ten of usefulness, BBC BASIC was several points ahead
 of the competition, scoring a relatively respectable zero.' --- Peter Corlett

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Johannes Schindelin escreveu:
> There's a bash src in the Snapshot package of MinGW:
> 
> 	http://prdownloads.sf.net/mingw/bash-2.05b-MSYS-src.tar.bz2?download

this thoroughly confuses me. 

Does it require MSYS? If yes, where can I find the MSYS source code?

What does it mean that: 

However, it is important to remember that NO executables other than
what ships with MSYS should be placed in the MSYS " bin"
subdirectory. Therefore, do not attempt to "merge" the two packages.
(http://www.mingw.org/mingwfaq.shtml#faq-msys)

If this is true, this will mess up my installers.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Johannes Schindelin]

Hi,

On Sun, 27 May 2007, Han-Wen Nienhuys wrote:

> there is a
> 
> bin/msys-1.0.dll
> bin/libW11.dll
> 
> inside the tarball. I want to know what they are, and how to build them.

Oops. I missed that. I guess that msys-1.0.dll is built from

	http://downloads.sourceforge.net/mingw/msys-1.0.10-src.tar.bz2

and that libW11.dll is built from some package in

	http://sourceforge.net/project/showfiles.php?group_id=37352

Ciao,
Dscho

Re: GIT on MinGW problem

[Aaron Gray]

> Han-Wen Nienhuys wrote:
>> 
>> Aaron Gray escreveu:
>> > Hello,
>> >
>> > I have installed the git-1.5.1-1.mingw.exe from
>> > http://lilypond.org/git/binaries/mingw/.
>> >
>> > On typing 'git' I get a message box saying :-
>> >
>> >        The procedure entry point libiconv could not be located in the
>> > dynamic link library libiconv-2.dll.
>> >
>> > I cannot seem to find libiconv-2.dll anywhere either.
>> 
>> This should be fixed in
>> 
>> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe
>> 
>> it should also set $PATH.
> 
> I gave this some more testing and it turns out to be a well working
> toolset. Thank you very much!
> 
> There were still some issues remaining. These are the ones that should
> be fixable easily:
> 
> * git version reports just:
> 
> git version -dirty
> 
> Since git-gui parses the output of git version, but does not expect it
> to be of this format, and fails with an error message that it cannot
> parse the version.
> 
> * git without an correct git subcommand should list 20 or so commands,
> but it doesn't. The list is just empty.
> 
> * I personally think that the files should go into
> 
> $PROGRAMFILES/Git/{bin,share,lib}
> instead of
> $PROGRAMFILES/Git/usr/{bin,share,lib}
> 
> The more difficult to solve problems are:
> 
> * git-gui and gitk don't work out of the box because they have the path
> to wish hardcoded. They can't be started from CMD at all. I have written
> wrappers gitk.cmd and git-gui.cmd with these 2 lines:
> 
> @echo off
> start wish84 D:/MSYS/1.0/git/bin/gitk %*
> 
> But as you can see, the path is still hard-coded (but it is good enough
> for me for the moment).
> 
> * perl scripts like git-remote contain a hard-coded path to the
> installation directory and don't work for this reason.

Are git init and git clone working for you ?

Aaron

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Johannes Sixt escreveu:
>>
>> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe
>>
>> it should also set $PATH.
> 
> I gave this some more testing and it turns out to be a well working
> toolset. Thank you very much!
> 
> There were still some issues remaining. These are the ones that should
> be fixable easily:
> 
> * git version reports just:
> 
> 	git version -dirty
> 
> Since git-gui parses the output of git version, but does not expect it
> to be of this format, and fails with an error message that it cannot
> parse the version.

My biggest problem is that the makefiles of git are an unmitigated
disaster, and there seems to be little interest in solving this
problem. For example, my suggestion to introduce autoconf was met with
derision.  Most of the effort was patching out makefile parts that
made my life harder. I may have patched the version part out as well.

In this, part of the pain is that Git tries to guess the version number
by itself in a complicated way.  It would be easiest if I could just 
specify the version number externally. In that case I can sync the installer
version number (1.5.1-2 in this case) and the version that git reports.


> * git without an correct git subcommand should list 20 or so commands,
> but it doesn't. The list is just empty.


there was a problem in generate cmd list,  (I have sort in /bin/ ). I
recommend to add

  set -u -v   

to all shell scripts so this doesn't go unnoticed.

> * I personally think that the files should go into
> 
> 	$PROGRAMFILES/Git/{bin,share,lib}
> instead of
> 	$PROGRAMFILES/Git/usr/{bin,share,lib}
> 
> The more difficult to solve problems are:

I understand, but it makes my life a lot more difficult.

> * git-gui and gitk don't work out of the box because they have the path
> to wish hardcoded. They can't be started from CMD at all. I have written
> wrappers gitk.cmd and git-gui.cmd with these 2 lines:
> 
> @echo off
> start wish84 D:/MSYS/1.0/git/bin/gitk %*
> 
> But as you can see, the path is still hard-coded (but it is good enough
> for me for the moment).

The only solution is to x-compile wish and include it as well.  I need several 
strong drinks to start trying this.  Is there a MinGW wish port?

> * perl scripts like git-remote contain a hard-coded path to the
> installation directory and don't work for this reason.

I actually commented out most perl stuff because the Makefile is just
too spaghetti-ish. I seem to have forgotten commenting out git-remote.

I thought the policy was to abandon Perl scripts for git commands?

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Johannes Schindelin]

Hi,

On Sat, 26 May 2007, Han-Wen Nienhuys wrote:

> Johannes Sixt escreveu:
> >>
> >> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe
> >>
> >> it should also set $PATH.
> > 
> > I gave this some more testing and it turns out to be a well working
> > toolset. Thank you very much!
> > 
> > There were still some issues remaining. These are the ones that should
> > be fixable easily:
> > 
> > * git version reports just:
> > 
> > 	git version -dirty
> > 
> > Since git-gui parses the output of git version, but does not expect it
> > to be of this format, and fails with an error message that it cannot
> > parse the version.
> 
> My biggest problem is that the makefiles of git are an unmitigated
> disaster, and there seems to be little interest in solving this
> problem. For example, my suggestion to introduce autoconf was met with
> derision.

Well, I would not call it derision. But many people have had bad 
experience with that big mess which is autoconf, so we were more than 
reluctant to do it.

In the meantime, we do have a configure.ac, though. In general, you do not 
have to run it, but you can if "make" does not work out of the box.

I have to admit that it is unclear to me what are the problems with the 
Makefile with regards to gub. I think I will just bite the apple, and 
download that beast to try it myself.

> In this, part of the pain is that Git tries to guess the version number
> by itself in a complicated way.

Yes, I never understood that myself why it has to be so complicated. But 
then, it did not make _my_ life hard, so I did not care.

> I thought the policy was to abandon Perl scripts for git commands?

Alas, no. We even have picked up a few since.

OTOH, it _is_ a nice thing to protohype the new commands as shell or perl 
scripts. When they stabilize enough, convert them to builtins.

There are exactly 4 perl scripts left that I regularly use:

add--interactive, cvsimport, remote and svn.

I somehow have the feeling that it is not worth the effort to convert 
cvsimport and svn. With add--interactive, I think it's better to leave it 
as is before Junio goes on another "what have I done? why did I have to 
add _this_?" spree.

But remote will soon be the center of my crosshairs.

Ciao,
Dscho

Re: GIT on MinGW problem

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> In this, part of the pain is that Git tries to guess the version number
>> by itself in a complicated way.
>
> Yes, I never understood that myself why it has to be so complicated. But 
> then, it did not make _my_ life hard, so I did not care.

"echo "MyVersionNumber" >version && make"?

> OTOH, it _is_ a nice thing to protohype the new commands as shell or perl 
> scripts. When they stabilize enough, convert them to builtins.

Protohype is a nice word.  Throw out a half-working stuff and
advertise it as the best thing since sliced bread even before it
starts to being useful ;-)

> There are exactly 4 perl scripts left that I regularly use:
>
> add--interactive, cvsimport, remote and svn.
>
> I somehow have the feeling that it is not worth the effort to convert 
> cvsimport and svn. With add--interactive, I think it's better to leave it 
> as is before Junio goes on another "what have I done? why did I have to 
> add _this_?" spree.

I do not follow you here.

> But remote will soon be the center of my crosshairs.

I am afraid that it might be a bit premature.

I've been hoping that we can make git-clone a thin wrapper
around init/remote/fetch/checkout.  For one thing, we would want
to split the separate-remotes layout and bareness to create
"mirror" (I called it "pure" previously, but this is really a
mirror) layout for git-clone, among other things, and that kind
of enhancements would need to be done inside git-remote.

Re: GIT on MinGW problem

[Johannes Schindelin]

Hi,

On Sat, 26 May 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> In this, part of the pain is that Git tries to guess the version number
> >> by itself in a complicated way.
> >
> > Yes, I never understood that myself why it has to be so complicated. But 
> > then, it did not make _my_ life hard, so I did not care.
> 
> "echo "MyVersionNumber" >version && make"?

Good to know!

> > OTOH, it _is_ a nice thing to protohype the new commands as shell or perl 
> > scripts. When they stabilize enough, convert them to builtins.
> 
> Protohype is a nice word.  Throw out a half-working stuff and
> advertise it as the best thing since sliced bread even before it
> starts to being useful ;-)

It started out as a typo. But then I liked it so much that I kept it ;-)

> > With add--interactive, I think it's better to leave it [...]
> 
> I do not follow you here.

You mentioned several times that you were unsure if add--interactive was a 
good idea. But I like it very much.

> 
> > But remote will soon be the center of my crosshairs.
> 
> I am afraid that it might be a bit premature.
> 
> I've been hoping that we can make git-clone a thin wrapper
> around init/remote/fetch/checkout.  For one thing, we would want
> to split the separate-remotes layout and bareness to create
> "mirror" (I called it "pure" previously, but this is really a
> mirror) layout for git-clone, among other things, and that kind
> of enhancements would need to be done inside git-remote.

Fair enough.

Ciao,
Dscho

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Johannes Schindelin escreveu:
>>> * git version reports just:
>>>
>>> 	git version -dirty
>>>
>>> Since git-gui parses the output of git version, but does not expect it
>>> to be of this format, and fails with an error message that it cannot
>>> parse the version.
>> My biggest problem is that the makefiles of git are an unmitigated
>> disaster, and there seems to be little interest in solving this
>> problem. For example, my suggestion to introduce autoconf was met with
>> derision.
> 
> Well, I would not call it derision. But many people have had bad 
> experience with that big mess which is autoconf, so we were more than 
> reluctant to do it.

autoconf is not that big a mess, but it is a macrolanguage, which does
come with its pitfalls.  Automake and libtool are the messy things,
and I prefer to stay away from them as far as possible.

The point of autoconf is to generate a hyper-portable script that
deals with all the different flavors of shell breakage.  For the user
it simplifies compiling packages enormously, which IMO should be the
guiding concern if you like to have users.

For a pretty run-of-the-mill tool like git (dependency wise), it
should be easy to write a working configure.in.

My favorite approach is: use autoconf to generate

 - config.h
 
 - config.make

All settings that force recompile should be in config.h, and standard
C methods to track dependencies will take care of the recompilation
when anything changes.  The main Makefile includes config.make, and
contains all configurable settings. The Makefile only needs to be
edited by developers. Require GNU Make so you can write sane
makefiles.

Instead, we have a Makefile that relies on an esoteric combination of
perl and shell scripting inside Makefiles.

Also, the Makefile says.

  # Shell quote (do not use $(call) to accommodate ancient setups);

I think it would be better to have a clearly defined list of optional
and required dependencies with version numbers, and then stand by
that.  For example, Make uses a completely autoconf/libtool based
compile process, and is easy to compile. I think it would be
reasonable to require a recent make, say 3.80, and then use its
features. 

> In the meantime, we do have a configure.ac, though. In general, you do not 
> have to run it, but you can if "make" does not work out of the box.
> 
> I have to admit that it is unclear to me what are the problems with the 
> Makefile with regards to gub. I think I will just bite the apple, and 
> download that beast to try it myself.

>From what I recall, it tries to be too clever in detecting changes 
of the make command line, forcing a recompile (possibly with erroneous paths)
during the 

  make install

I might be mistaken, though. I tried to get something up as fast as
possible.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Jakub Narebski]

Han-Wen Nienhuys wrote:

> Johannes Schindelin escreveu:

>>>> * git version reports just:
>>>>
>>>>    git version -dirty
>>>>
>>>> Since git-gui parses the output of git version, but does not expect it
>>>> to be of this format, and fails with an error message that it cannot
>>>> parse the version.
>>> My biggest problem is that the makefiles of git are an unmitigated
>>> disaster, and there seems to be little interest in solving this
>>> problem. For example, my suggestion to introduce autoconf was met with
>>> derision.
>> 
>> Well, I would not call it derision. But many people have had bad 
>> experience with that big mess which is autoconf, so we were more than 
>> reluctant to do it.
> 
> autoconf is not that big a mess, but it is a macrolanguage, which does
> come with its pitfalls.  Automake and libtool are the messy things,
> and I prefer to stay away from them as far as possible.
> 
> The point of autoconf is to generate a hyper-portable script that
> deals with all the different flavors of shell breakage.  For the user
> it simplifies compiling packages enormously, which IMO should be the
> guiding concern if you like to have users.
> 
> For a pretty run-of-the-mill tool like git (dependency wise), it
> should be easy to write a working configure.in.
> 
> My favorite approach is: use autoconf to generate
> 
>  - config.h
>  
>  - config.make
> 
> All settings that force recompile should be in config.h, and standard
> C methods to track dependencies will take care of the recompilation
> when anything changes.  The main Makefile includes config.make, and
> contains all configurable settings. The Makefile only needs to be
> edited by developers. Require GNU Make so you can write sane
> makefiles.

Actually we do have configure.ac script; ./configure (result of
"make configure") is not distributed in the tarball I think.
It generates file named not config.make, but config.mak.autogen.
By the way, the .autogen suffix is to distinguish ./configure generated file
from handmade user configureation, but I have no idea why it is config.mak
not config.make. But there is no config.h -- we do not rely on automake and
autoheader.

If you are well wersed in autoconf, feel free to improve our configure.ac
script.
 
> Instead, we have a Makefile that relies on an esoteric combination of
> perl and shell scripting inside Makefiles.

The idea is to be able to get reasonable defaults (depending on system of
course) without needing autoconf, and running quite long on some
platform ./configure script detection...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Jakub Narebski escreveu:

>> Instead, we have a Makefile that relies on an esoteric combination of
>> perl and shell scripting inside Makefiles.
> 
> The idea is to be able to get reasonable defaults (depending on system of

This saves the user on Linux or similar platform one ./configure call. For
the rest it means editing makefiles. I'm not sure if that is an improvement
over the standard 

  configure ; make ; make install

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Shawn O. Pearce]

Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
> Jakub Narebski escreveu:
> 
> >> Instead, we have a Makefile that relies on an esoteric combination of
> >> perl and shell scripting inside Makefiles.
> > 
> > The idea is to be able to get reasonable defaults (depending on system of
> 
> This saves the user on Linux or similar platform one ./configure call. For
> the rest it means editing makefiles. I'm not sure if that is an improvement
> over the standard 
> 
>   configure ; make ; make install

[side note: can you please not send both To the list and CC the
list on the same message?  Pick one, we're all getting two copies
of messages from you.]

On systems like Cygwin the fork+exec overheads are very high;
running a "simple" configure script can take longer than it
takes me to compile Git from scratch.  Editing config.mak is
quite easy; so is passing your choices on the command line to
`make install`.

Personally I find:

	make NO_CURL=1 install

easier than:

	./configure --without-curl && make install

-- 
Shawn.

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Shawn O. Pearce escreveu:
> 
> On systems like Cygwin the fork+exec overheads are very high;
> running a "simple" configure script can take longer than it
> takes me to compile Git from scratch.  Editing config.mak is
> quite easy; so is passing your choices on the command line to
> `make install`.
> 
> Personally I find:
> 
> 	make NO_CURL=1 install
> 
> easier than:
> 
> 	./configure --without-curl && make install

NO_CURL is a nonstandard option. Every package does it
differently, so this requires users to delve through either
INSTALL or Makefile. 

A well written configure script is able to detect presence
of a linkable libcurl. 

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Steven Grimm]

Han-Wen Nienhuys wrote:
>> On systems like Cygwin the fork+exec overheads are very high
> A well written configure script is able to detect presence
> of a linkable libcurl. 
>   

IMO the reasons configure is so unwieldy, at least as it's set up in 
most open source projects, are that a) it spends 95% of its time 
checking for things that basically never vary (yes, I have stdlib.h, 
thank you) and that b) it doesn't remember the results from previous 
runs on the same host (I'm just changing the install path; my ints won't 
have stopped being 32 bits as a result.) I wonder if we could satisfy 
most people with a configure script -- maybe not based on autoconf -- 
that is limited in scope to just the things that are currently tweakable 
in the git Makefile.

If configure ran only, say, 10-15 tests, I bet the fork+exec overhead on 
Cygwin would be perfectly tolerable.

-Steve

Re: GIT on MinGW problem

[Jakub Narebski]

On Sun, 27 May 2007, Steven Grimm wrote:
> Han-Wen Nienhuys wrote:
>> Shawn O. Pearce escreveu:
>>>
>>> On systems like Cygwin the fork+exec overheads are very high
>>
>> A well written configure script is able to detect presence
>> of a linkable libcurl.
> 
> IMO the reasons configure is so unwieldy, at least as it's set up in 
> most open source projects, are that a) it spends 95% of its time 
> checking for things that basically never vary (yes, I have stdlib.h, 
> thank you) and that b) it doesn't remember the results from previous 
> runs on the same host (I'm just changing the install path; my ints won't 
> have stopped being 32 bits as a result.)

./configure _can_ cache tests results:

$ ./configure --help
[...]
      --cache-file=FILE   cache test results in FILE [disabled]
  -C, --config-cache      alias for `--cache-file=config.cache'

but it does not do this, and does not check chache by default. Of course
tests have to be written to make use of cache, IIRC...

> I wonder if we could satisfy  
> most people with a configure script -- maybe not based on autoconf -- 
> that is limited in scope to just the things that are currently tweakable 
> in the git Makefile.

The problem with handcrafted configure script lies in the portability
of it. There was an attempt to add such script, IIRC based on mplayer's
configure.sh script, but it turned out it was not portable enough.
The conclusion was that sice so many manhours were put into making
autoconf generate ultra-portable ./configure shell script, it would
be better to use it.

> If configure ran only, say, 10-15 tests, I bet the fork+exec overhead on 
> Cygwin would be perfectly tolerable.

That's not only fork+exec, that is also the fact that large number
of tests relies on compiling snippets of code...


P.S. What do you think about separating the guessing appropriate
values of build variables based on uname to separate file
config.mak.guess, included in Makefile?

-- 
Jakub Narebski
Poland

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Jakub Narebski escreveu:
> On Sun, 27 May 2007, Steven Grimm wrote:
>> Han-Wen Nienhuys wrote:
>>> Shawn O. Pearce escreveu:
>>>> On systems like Cygwin the fork+exec overheads are very high
>>> A well written configure script is able to detect presence
>>> of a linkable libcurl.
>> IMO the reasons configure is so unwieldy, at least as it's set up in 
>> most open source projects, are that a) it spends 95% of its time 
>> checking for things that basically never vary (yes, I have stdlib.h, 
>> thank you) and that b) it doesn't remember the results from previous 
>> runs on the same host (I'm just changing the install path; my ints won't 
>> have stopped being 32 bits as a result.)
> 
> ./configure _can_ cache tests results:
> 
> $ ./configure --help
> [...]
>       --cache-file=FILE   cache test results in FILE [disabled]
>   -C, --config-cache      alias for `--cache-file=config.cache'
> 
> but it does not do this, and does not check chache by default. Of course
> tests have to be written to make use of cache, IIRC...

Slowness is a misguided argument as well.  Yes, configure is slow, but you
only have to run it if configure.in , config.h.in or config.make.in chagnes.
And that doesn't happen very often during development.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Johannes Schindelin]

Hi,

On Sun, 27 May 2007, Han-Wen Nienhuys wrote:

> Jakub Narebski escreveu:
> > On Sun, 27 May 2007, Steven Grimm wrote:
> >> Han-Wen Nienhuys wrote:
> >>> Shawn O. Pearce escreveu:
> >>>> On systems like Cygwin the fork+exec overheads are very high
> >>> A well written configure script is able to detect presence
> >>> of a linkable libcurl.
> >> IMO the reasons configure is so unwieldy, at least as it's set up in 
> >> most open source projects, are that a) it spends 95% of its time 
> >> checking for things that basically never vary (yes, I have stdlib.h, 
> >> thank you) and that b) it doesn't remember the results from previous 
> >> runs on the same host (I'm just changing the install path; my ints won't 
> >> have stopped being 32 bits as a result.)
> > 
> > ./configure _can_ cache tests results:
> > 
> > $ ./configure --help
> > [...]
> >       --cache-file=FILE   cache test results in FILE [disabled]
> >   -C, --config-cache      alias for `--cache-file=config.cache'
> > 
> > but it does not do this, and does not check chache by default. Of course
> > tests have to be written to make use of cache, IIRC...
> 
> Slowness is a misguided argument as well.  Yes, configure is slow, but 
> you only have to run it if configure.in , config.h.in or config.make.in 
> chagnes. And that doesn't happen very often during development.

Slowness is a good argument. The config does change from time to time (you 
should know, IICC LilyPond had 36 changes in configure.in through 2006). 
And it is annoying.

Especially when you are trying to debug ./configure.

Ciao,
Dscho

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Johannes Schindelin escreveu:
>>> but it does not do this, and does not check chache by default. Of course
>>> tests have to be written to make use of cache, IIRC...
>> Slowness is a misguided argument as well.  Yes, configure is slow, but 
>> you only have to run it if configure.in , config.h.in or config.make.in 
>> chagnes. And that doesn't happen very often during development.
> 
> Slowness is a good argument. The config does change from time to time (you 
> should know, IICC LilyPond had 36 changes in configure.in through 2006). 

Compared to the 100 recompiles during a typical debug/compile day, that's 
not very significant, IMO.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Johannes Schindelin]

Hi,

On Sun, 27 May 2007, Han-Wen Nienhuys wrote:

> Jakub Narebski escreveu:
> 
> >> Instead, we have a Makefile that relies on an esoteric combination of 
> >> perl and shell scripting inside Makefiles.
> > 
> > The idea is to be able to get reasonable defaults (depending on system 
> > of
> 
> This saves the user on Linux or similar platform one ./configure call. 

It works on Linux, Cygwin, MinGW, last time I checked MacOSX, IRIX, and I 
imagine Solaris, AIX and even other platforms, out of the box.

> For the rest it means editing makefiles. I'm not sure if that is an 
> improvement over the standard
> 
>   configure ; make ; make install

ATM you have to do autoconf before that. But that should work, really.

Ciao,
Dscho

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Han-Wen Nienhuys escreveu:
> The only solution is to x-compile wish and include it as well.  I need several 
> strong drinks to start trying this.  Is there a MinGW wish port?

It turns out that spending a night in a brazilian/japanese karaoke bar
where thumping disco beats of the sadly deserted dance area permeates
the bleary out-of-tune portuguese singing of hormonally driven women did
enough to melt my mind.

There is a 1.5.2-3 installer which includes a cross-compiled tcltk. 

  http://lilypond.org/git/binaries/mingw/

What is the proper way to have the 'gitk' command start up with wish
automatically?


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

GIT on MinGW, with tcltk for gitk

[Han-Wen Nienhuys]

Han-Wen Nienhuys escreveu:
> There is a 1.5.2-3 installer which includes a cross-compiled tcltk. 
> 
>   http://lilypond.org/git/binaries/mingw/
> 
> What is the proper way to have the 'gitk' command start up with wish
> automatically?

I've just uploaded 1.5.2-5, which also writes a gitk.bat file, containing
proper paths. However, I can't get it working in Wine. Any windows user
that cares to test? 

  http://lilypond.org/git/binaries/mingw/git-1.5.2-5.mingw.exe

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW, with tcltk for gitk

[Aaron Gray]

> Han-Wen Nienhuys escreveu:
>> There is a 1.5.2-3 installer which includes a cross-compiled tcltk. 
>> 
>>   http://lilypond.org/git/binaries/mingw/
>> 
>> What is the proper way to have the 'gitk' command start up with wish
>> automatically?
> 
> I've just uploaded 1.5.2-5, which also writes a gitk.bat file, containing
> proper paths. However, I can't get it working in Wine. Any windows user
> that cares to test? 
> 
>  http://lilypond.org/git/binaries/mingw/git-1.5.2-5.mingw.exe
> 

git clone or git-clone are not accessable still.

C:\Work\test>git init
warning: templates not found C:/Program Files/Git/usr/bin@template_dir@
Initialized empty Git repository in .git/

Aaron

Re: GIT on MinGW, with tcltk for gitk

[Han-Wen Nienhuys]

Aaron Gray escreveu:

> C:\Work\test>git init
> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@
> Initialized empty Git repository in .git/
> 
> Aaron

Thanks for the report. Can you try again with 1.5.2-7  ? It should be available
in a few minutes.

Also, can you tell me if gitk.bat works for you?

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW, with tcltk for gitk

[Aaron Gray]

> Aaron Gray escreveu:
>
>> C:\Work\test>git init
>> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@
>> Initialized empty Git repository in .git/
>>
>> Aaron
>
> Thanks for the report. Can you try again with 1.5.2-7  ? It should be 
> available
> in a few minutes.

Okay, I'm up for all the testing thats needed. Just dont know the territory 
that well though, as I am a Windozer :)

> Also, can you tell me if gitk.bat works for you?

Okay, I just type 'gitk' ?

And what happens ?

Thanks,

Aaron

Re: GIT on MinGW, with tcltk for gitk

[Aaron Gray]

>> Aaron Gray escreveu:
>>
>>> C:\Work\test>git init
>>> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@
>>> Initialized empty Git repository in .git/
>>>
>>> Aaron
>>
>> Thanks for the report. Can you try again with 1.5.2-7  ? It should be 
>> available
>> in a few minutes.
>
> Okay, I'm up for all the testing thats needed. Just dont know the 
> territory that well though, as I am a Windozer :)

git init appears to work fine now, the template path is found.

git clone or git-clone is still not working.

'git clone' just gives a list of git's commands.

git-clone gives usual :-

C:\Work\test2>git-clone git://git.kernel.org/pub/scm/git/git.git
'git-clone' is not recognized as an internal or external command,
operable program or batch file.

>> Also, can you tell me if gitk.bat works for you?
>
> Okay, I just type 'gitk' ?

C:\Work>gitk
'"C:\Program Files\Git\usr\bin\wish.exe"' is not recognized as an internal 
or external command, operable program or batch file.

Theres a file called 'wish84.exe' under 'C:\Program Files\Git\usr\bin', but 
no wish.exe.

Aaron

Aaron

Re: GIT on MinGW, with tcltk for gitk

[Han-Wen Nienhuys]

2007/5/27, Aaron Gray <angray@beeb.net>:

> '"C:\Program Files\Git\usr\bin\wish.exe"' is not recognized as an internal
> or external command, operable program or batch file.
>
> Theres a file called 'wish84.exe' under 'C:\Program Files\Git\usr\bin', but
> no wish.exe.

can you edit this .bat to say wish84.exe iso. wish.exe ?

thnks,

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW, with tcltk for gitk

[Aaron Gray]

> 2007/5/27, Aaron Gray <angray@beeb.net>:
>
>> '"C:\Program Files\Git\usr\bin\wish.exe"' is not recognized as an 
>> internal
>> or external command, operable program or batch file.
>>
>> Theres a file called 'wish84.exe' under 'C:\Program Files\Git\usr\bin', 
>> but
>> no wish.exe.
>
> can you edit this .bat to say wish84.exe iso. wish.exe ?

Getting message box saying :-

    child process exited abnormally
        while executing
    "close $refd"
        (proceedure "readrefs" line 47)
        invoked from within
    "readrefs"
        (file "C:\Program Files\Git\usr\bin\gitk line 6369)

:(

Aaron

Re: GIT on MinGW, with tcltk for gitk

[Han-Wen Nienhuys]

Aaron Gray escreveu:
>>>
>>> Theres a file called 'wish84.exe' under 'C:\Program
>>> Files\Git\usr\bin', but
>>> no wish.exe.
>>
>> can you edit this .bat to say wish84.exe iso. wish.exe ?
> 
> Getting message box saying :-
> 
>    child process exited abnormally
>        while executing
>    "close $refd"
>        (proceedure "readrefs" line 47)
>        invoked from within
>    "readrefs"
>        (file "C:\Program Files\Git\usr\bin\gitk line 6369)
> 
> :(

It seems that tcltk was executed; Unfortunately, it does work
flawlessly under wine, so there is little I can do.  I invite windows
experts to have a closer look.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW - No symbolic links support

[Aaron Gray]

Bit of a dampener on GIT on MinGW :-

        $ git clone git://git.kernel.org/pub/scm/git/git.git
        Initialized empty Git repository in C:/MSYS/src/git/.git/
        error: git-checkout-index: unable to create symlink RelNotes 
(Function not implemented)

No Symbolic links !

There are symbolic links provided by Windows by SFU (Services For Unix) 
apparently.

Aaron

 

Re: GIT on MinGW - No symbolic links support

[Johannes Schindelin]

Hi,

On Sun, 27 May 2007, Aaron Gray wrote:

> Bit of a dampener on GIT on MinGW :-
> 
>        $ git clone git://git.kernel.org/pub/scm/git/git.git
>        Initialized empty Git repository in C:/MSYS/src/git/.git/
>        error: git-checkout-index: unable to create symlink RelNotes (Function
> not implemented)
> 
> No Symbolic links !
> 
> There are symbolic links provided by Windows by SFU (Services For Unix)
> apparently.

Does not work on FAT. Has lots of problems.

That's why Johannes Sixt pushed for core.symlinks, and got it. So maybe 
the templates should set core.symlinks=false?

Ciao,
Dscho

Re: GIT on MinGW - No symbolic links support

[Johannes Sixt]

Johannes Schindelin wrote:
> 
> Hi,
> 
> On Sun, 27 May 2007, Aaron Gray wrote:
> 
> > Bit of a dampener on GIT on MinGW :-
> >
> >        $ git clone git://git.kernel.org/pub/scm/git/git.git
> >        Initialized empty Git repository in C:/MSYS/src/git/.git/
> >        error: git-checkout-index: unable to create symlink RelNotes (Function
> > not implemented)
> >
> > No Symbolic links !
> >
> > There are symbolic links provided by Windows by SFU (Services For Unix)
> > apparently.
> 
> Does not work on FAT. Has lots of problems.
> 
> That's why Johannes Sixt pushed for core.symlinks, and got it. So maybe
> the templates should set core.symlinks=false?

This setting should be placed into $(sysconfigdir)/gitconfig. I'll hack
up something in the next days. The "challenge" is that $(sysconfigdir)
must not be hardcoded (because the installation location is not known
until runtime). A similar thing I have already done with
$(template_dir).

-- Hannes

Re: GIT on MinGW, with tcltk for gitk

[Han-Wen Nienhuys]

Aaron Gray escreveu:
>>> Aaron Gray escreveu:
>>>
>>>> C:\Work\test>git init
>>>> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@
>>>> Initialized empty Git repository in .git/
>>>>
>>>> Aaron
>>>
>>> Thanks for the report. Can you try again with 1.5.2-7  ? It should be
>>> available
>>> in a few minutes.
>>
>> Okay, I'm up for all the testing thats needed. Just dont know the
>> territory that well though, as I am a Windozer :)
> 
> git init appears to work fine now, the template path is found.
> 
> git clone or git-clone is still not working.
> 

clone is a shell script. None of the shell scripts work; you'll have
to install msys bash yourself for now.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Johannes Sixt]

Han-Wen Nienhuys wrote:
> Johannes Sixt escreveu:
> > * git without an correct git subcommand should list 20 or so commands,
> > but it doesn't. The list is just empty.
> 
> there was a problem in generate cmd list,  (I have sort in /bin/ ). I
> recommend to add

Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the same
as /bin/sort.

(For the curious ones: The MinGW port has to replace occurrences of
'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be picked up
in shell scripts, because the latter usually comes first in
%PATH%^W$PATH. Same for 'find'.)

-- Hannes

Re: GIT on MinGW problem

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

Johannes Sixt said the following on 29.05.2007 12:54:
> Han-Wen Nienhuys wrote:
>> Johannes Sixt escreveu:
>>> * git without an correct git subcommand should list 20 or so
>>> commands, but it doesn't. The list is just empty.
>> there was a problem in generate cmd list,  (I have sort in /bin/
>> ). I recommend to add
> 
> Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the
> same as /bin/sort.
> 
> (For the curious ones: The MinGW port has to replace occurrences of
> 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be
> picked up in shell scripts, because the latter usually comes first
> in %PATH%^W$PATH. Same for 'find'.)

I get that here too, no matter what I set the mount point to be, and 
without the fstab file at all.

Also, the /bin/gitk.bat file should rather be
     @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %*
than the current hardcoded path. (Probably won't work with 
command.com, but who uses that for development nowadays anyways, right ;-)

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: GIT on MinGW problem

[Johannes Sixt]

Marius Storm-Olsen wrote:
> 
> Johannes Sixt said the following on 29.05.2007 12:54:
> > Han-Wen Nienhuys wrote:
> >> Johannes Sixt escreveu:
> >>> * git without an correct git subcommand should list 20 or so
> >>> commands, but it doesn't. The list is just empty.
> >> there was a problem in generate cmd list,  (I have sort in /bin/
> >> ). I recommend to add
> >
> > Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the
> > same as /bin/sort.
> >
> > (For the curious ones: The MinGW port has to replace occurrences of
> > 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be
> > picked up in shell scripts, because the latter usually comes first
> > in %PATH%^W$PATH. Same for 'find'.)
> 
> I get that here too, no matter what I set the mount point to be, and
> without the fstab file at all.

When I inserted '/usr/bin/sort' I had checked for 'which sort' on my
Linux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably
the canonical path to sort on any *nix. Will change that. But is this
also true for 'find'?

> Also, the /bin/gitk.bat file should rather be
>      @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %*
> than the current hardcoded path. (Probably won't work with
> command.com, but who uses that for development nowadays anyways, right ;-)

Nice trick! But don't try this at home without parental guidance! It
fills your screen with recursive console window invocations of itself.

I put this into gitk.cmd (didn't try .bat):

@start wish84.exe "%~d0%~p0gitk" %*

assuming wish84 is in the PATH (which is probably a sane assumption
because either it is part of the installer, in which case it should have
set up the PATH, or you have Tcl/Tk installed for some other reason, in
which case you will want to have it in the PATH, too).

Futhermore, I like to have the GUI sent into the background
automatically and without opening another console window, hence, the use
of 'start'.

-- Hannes

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

2007/5/29, Johannes Sixt <J.Sixt@eudaptics.com>:

> > I get that here too, no matter what I set the mount point to be, and
> > without the fstab file at all.
>
> When I inserted '/usr/bin/sort' I had checked for 'which sort' on my
> Linux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably
> the canonical path to sort on any *nix. Will change that. But is this
> also true for 'find'?


I suggest that you add $PATH  appropriately (prepending /bin and
/usr/bin/ ) and then
let the OS figure it out. The other option is to write an autoconf
test to discover the proper path.


> > Also, the /bin/gitk.bat file should rather be
> >      @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %*
> > than the current hardcoded path. (Probably won't work with
> > command.com, but who uses that for development nowadays anyways, right ;-)
>
> Nice trick! But don't try this at home without parental guidance! It
> fills your screen with recursive console window invocations of itself.
>
> I put this into gitk.cmd (didn't try .bat):
>
> @start wish84.exe "%~d0%~p0gitk" %*
>
> assuming wish84 is in the PATH (which is probably a sane assumption
> because either it is part of the installer, in which case it should have
> set up the PATH, or you have Tcl/Tk installed for some other reason, in
> which case you will want to have it in the PATH, too).
>
> Futhermore, I like to have the GUI sent into the background
> automatically and without opening another console window, hence, the use
> of 'start'.

I'll have a look at this when I have time. What the hell is

%~d0%~p0

?

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Johannes Sixt]

Han-Wen Nienhuys wrote:
> 
> 2007/5/29, Johannes Sixt <J.Sixt@eudaptics.com>:
> 
> > > I get that here too, no matter what I set the mount point to be, and
> > > without the fstab file at all.
> >
> > When I inserted '/usr/bin/sort' I had checked for 'which sort' on my
> > Linux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably
> > the canonical path to sort on any *nix. Will change that. But is this
> > also true for 'find'?
> 
> I suggest that you add $PATH  appropriately (prepending /bin and
> /usr/bin/ ) and then
> let the OS figure it out. The other option is to write an autoconf
> test to discover the proper path.

'sort' (and 'find' for that matter) is not only used by the build
scripts, but also by some shell scripts of the toolset. Hence, the path
would have to be modified for each 'git foo' invocation, IOW, by git.exe
itself. I don't like this solution.

The alternative, to force the user to put his $MSYSDIR/bin before $WINNT
(which would require admin rights, btw, because the system's PATH must
be modified), I like even less.

I've to think a bit more about this.

-- Hannes

Re: GIT on MinGW problem

[Johannes Schindelin]

Hi,

On Tue, 29 May 2007, Marius Storm-Olsen wrote:

> Johannes Sixt said the following on 29.05.2007 12:54:
> > Han-Wen Nienhuys wrote:
> > > Johannes Sixt escreveu:
> > > > * git without an correct git subcommand should list 20 or so
> > > > commands, but it doesn't. The list is just empty.
> > > there was a problem in generate cmd list,  (I have sort in /bin/
> > > ). I recommend to add
> > 
> > Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the
> > same as /bin/sort.
> > 
> > (For the curious ones: The MinGW port has to replace occurrences of
> > 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be
> > picked up in shell scripts, because the latter usually comes first
> > in %PATH%^W$PATH. Same for 'find'.)
> 
> I get that here too, no matter what I set the mount point to be, and without
> the fstab file at all.
> 
> Also, the /bin/gitk.bat file should rather be
>     @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %*
> than the current hardcoded path. (Probably won't work with command.com, but
> who uses that for development nowadays anyways, right ;-)

We're open source, so we _can_ do better than leaving people stuck on 
older hardware behind.

And I don't know what this garbage means. (I checked with GMane, and it 
looks the same there.) I'd rather have something readable, even if it is 
slightly slower or has to be adjusted when installing.

Ciao,
Dscho

Re: GIT on MinGW problem

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

Johannes Schindelin said the following on 29.05.2007 14:11:
>> Also, the /bin/gitk.bat file should rather be 
>> @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %* than the current
>> hardcoded path. (Probably won't work with command.com, but who
>> uses that for development nowadays anyways, right ;-)
> 
> We're open source, so we _can_ do better than leaving people stuck
> on older hardware behind.
> 
> And I don't know what this garbage means. (I checked with GMane,
> and it looks the same there.) I'd rather have something readable,
> even if it is slightly slower or has to be adjusted when
> installing.

%~d0 = expands %0 to a drive letter only
%~p0 = expands %0 to a path only

so, for
     C:\foo\bar\baz\gitk.bat
%~d0%~p0gitk would expand to
     C:\foo\bar\baz\gitk

Looking at the docs for cmd's call (run 'help call'), I see now that 
it can be written
     %~dp0gitk
as well..

Anyways, if people are critical to not supporting the command.com, 
then you could do something like the following. (Note that for 
command.com it would be the old behavior were you need to replace the 
path if you install Git somewhere else, while for cmd.exe users it 
will just work. I'm sure magic can be done to make it work with 
command.com as well, but I'll leave that up to someone else to play with):

---
@echo off
REM This GOTO relies on the hack that command.com only supports
REM 8 character labels, so it reads 'goto _Windows'
goto :_WindowsNT

REM Command.com jumps here
:_Windows
wish84.exe "C:\Git\usr\bin\gitk" %1 %2 %3 %4 %5 %6 %7 %8 %9
REM NOTE! If you install Git in some other path, and use
REM command.com, you need to replace the path above

goto :EOF

REM Cmd.exe jumps here
:_WindowsNT
start wish84.exe "%~dp0gitk" %*

:EOF

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: GIT on MinGW problem

[Johannes Sixt]

Marius Storm-Olsen wrote:
> 
> Johannes Schindelin said the following on 29.05.2007 14:11:
> >> Also, the /bin/gitk.bat file should rather be
> >> @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %* than the current
> >> hardcoded path. (Probably won't work with command.com, but who
> >> uses that for development nowadays anyways, right ;-)
> >
> > We're open source, so we _can_ do better than leaving people stuck
> > on older hardware behind.
> >
> > And I don't know what this garbage means. (I checked with GMane,
> > and it looks the same there.) I'd rather have something readable,
> > even if it is slightly slower or has to be adjusted when
> > installing.
> 
> %~d0 = expands %0 to a drive letter only
> %~p0 = expands %0 to a path only
> 
> so, for
>      C:\foo\bar\baz\gitk.bat
> %~d0%~p0gitk would expand to
>      C:\foo\bar\baz\gitk
> 
> Looking at the docs for cmd's call (run 'help call'), I see now that
> it can be written
>      %~dp0gitk
> as well..

But... the docs also say that this stuff is only available if command
extensions are turned on. Are they on by default?

(I cannot tell because I remember faintly that I fiddled with the
corresponding registry setting in the past, but don't know whether it
was on or off at the beginning.)

-- Hannes

Re: GIT on MinGW problem

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

Johannes Sixt said the following on 29.05.2007 15:24:
>> Looking at the docs for cmd's call (run 'help call'), I see now that
>> it can be written
>>      %~dp0gitk
>> as well..
> 
> But... the docs also say that this stuff is only available if command
> extensions are turned on. Are they on by default?
> 
> (I cannot tell because I remember faintly that I fiddled with the
> corresponding registry setting in the past, but don't know whether it
> was on or off at the beginning.)

Ok, MSDN says it on by default on XP, while other docs say its on by
default without specifying any platforms. Also, it might be that the
%~dp0 construct is only supported on later versions of the cmd
extension too (I don't have NT 4, so I can't test this), so to be on
the safe side you can do this:

----
@echo off
REM This GOTO relies on the hack that command.com only supports
REM 8 character labels, so it reads 'goto _Windows'
goto :_WindowsNT

REM Command.com jumps here
:_Windows
wish84.exe "C:\Git\usr\bin\gitk" %1 %2 %3 %4 %5 %6 %7 %8 %9
REM NOTE! If you install Git in some other path, and use
REM command.com, you need to replace the path above

goto :EOF

REM Cmd.exe jumps here
:_WindowsNT
if "%1" neq "ensureExt" (
    REM Call the script again with cmd /X to explicitly turn on Command Extensions
    %COMSPEC% /X /C "%0 ensureExt %*"
    goto :EOF
)

REM If our CMD Extension version is less than 2, we might not support the %~dp0
REM construct so, just do the normal _Windows call instead. (This should only
REM happen on old Windows NT 4, where the extension is not so sophisticated
if not cmdextversion 2 (
    call :_Windows %2 %3 %4 %5 %6 %7 %8 %9
    goto :EOF
)
start wish84.exe "%~dp0gitk" %2 %3 %4 %5 %6 %7 %8 %9

:EOF

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: GIT on MinGW problem

[Johannes Schindelin]

Hi,

On Tue, 29 May 2007, Marius Storm-Olsen wrote:

> Looking at the docs for cmd's call (run 'help call'), [...]

Which one?

There are at least three different cmd.exe that _I_ encountered: NT4.0, 
2000 and XP. All of them have different features. None of my scripts 
worked without _heavy_ workarounding on all of them.

But I think a .lnk file would be easier to create, and more portable, 
right?

Ciao,
Dscho

Re: GIT on MinGW problem

[Johannes Sixt]

Johannes Schindelin wrote:
> There are at least three different cmd.exe that _I_ encountered: NT4.0,
> 2000 and XP. All of them have different features. None of my scripts
> worked without _heavy_ workarounding on all of them.
> 
> But I think a .lnk file would be easier to create, and more portable,
> right?

If:

1. there is a .lnk file named gitk.lnk with target for example:

    D:\MSYS\1.0\mingw\bin\wish84.exe D:\MSYS\1.0\git\bin\gitk

2. you change PATHEXT to include '.LNK'.

then gitk can be invoked with varying arguments from CMD. I've tested
this only on W2k. Point 2 looks hackish and dangerous to me.

-- Hannes

Re: GIT on MinGW problem

[Nguyen Thai Ngoc Duy]

On 5/29/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Johannes Schindelin wrote:
> > There are at least three different cmd.exe that _I_ encountered: NT4.0,
> > 2000 and XP. All of them have different features. None of my scripts
> > worked without _heavy_ workarounding on all of them.
> >
> > But I think a .lnk file would be easier to create, and more portable,
> > right?
>
> If:
>
> 1. there is a .lnk file named gitk.lnk with target for example:
>
>     D:\MSYS\1.0\mingw\bin\wish84.exe D:\MSYS\1.0\git\bin\gitk
>
> 2. you change PATHEXT to include '.LNK'.
>
> then gitk can be invoked with varying arguments from CMD. I've tested
> this only on W2k. Point 2 looks hackish and dangerous to me.

I'd suggest create a small C wrapper to launch gitk. It would be much
easier that way IMHO.

-- 
Duy

Re: GIT on MinGW problem

[Johannes Sixt]

Nguyen Thai Ngoc Duy wrote:
> I'd suggest create a small C wrapper to launch gitk. It would be much
> easier that way IMHO.

Doh! You're right! It's even there already, right before our eyes:

pointy..clicky..pointy..clicky  (aka: cp gitk git-k)

$ git k

:)

-- Hannes

Re: GIT on MinGW problem

[Nguyen Thai Ngoc Duy]

On 5/29/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Nguyen Thai Ngoc Duy wrote:
> > I'd suggest create a small C wrapper to launch gitk. It would be much
> > easier that way IMHO.
>
> Doh! You're right! It's even there already, right before our eyes:
>
> pointy..clicky..pointy..clicky  (aka: cp gitk git-k)
>
> $ git k
>
> :)

Maybe we should teach git.c to try gitk if git-k is not found ;)

> -- Hannes
>
>


-- 
Duy

[PATCH] Make git-k an alias to gitk

[Johannes Schindelin]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

On Tue, 29 May 2007, Nguyen Thai Ngoc Duy wrote:

	> On 5/29/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
	> > Nguyen Thai Ngoc Duy wrote:
	> > > I'd suggest create a small C wrapper to launch gitk. It 
	> > > would be much easier that way IMHO.
	> > 
	> > Doh! You're right! It's even there already, right before our 
	> > eyes:
	> > 
	> > pointy..clicky..pointy..clicky  (aka: cp gitk git-k)
	> > 
	> > $ git k
	> > 
	> > :)
	> 
	> Maybe we should teach git.c to try gitk if git-k is not found ;)

	Something like this?

 Makefile |    2 +-
 git.c    |    6 ++++++
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 5f94630..01ab1ff 100644
--- a/Makefile
+++ b/Makefile
@@ -262,7 +262,7 @@ EXTRA_PROGRAMS =
 BUILT_INS = \
 	git-format-patch$X git-show$X git-whatchanged$X git-cherry$X \
 	git-get-tar-commit-id$X git-init$X git-repo-config$X \
-	git-fsck-objects$X git-cherry-pick$X \
+	git-fsck-objects$X git-cherry-pick$X git-k$X \
 	$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
 
 # what 'all' will build and 'install' will install, in gitexecdir
diff --git a/git.c b/git.c
index 04eb344..53d81e9 100644
--- a/git.c
+++ b/git.c
@@ -216,6 +216,11 @@ static int handle_alias(int *argcp, const char ***argv)
 	return ret;
 }
 
+static int cmd_gitk(int argc, const char **argv, const char *prefix)
+{
+	return execv("gitk", (char *const *)argv);
+}
+
 const char git_version_string[] = GIT_VERSION;
 
 #define RUN_SETUP	(1<<0)
@@ -274,6 +279,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
 		{ "help", cmd_help },
 		{ "init", cmd_init_db },
 		{ "init-db", cmd_init_db },
+		{ "k", cmd_gitk },
 		{ "log", cmd_log, RUN_SETUP | USE_PAGER },
 		{ "ls-files", cmd_ls_files, RUN_SETUP },
 		{ "ls-tree", cmd_ls_tree, RUN_SETUP },
-- 
1.5.2.2641.g404de-dirty

Re: [PATCH] Make git-k an alias to gitk

[Johannes Sixt]

Johannes Schindelin wrote:
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> 
> On Tue, 29 May 2007, Nguyen Thai Ngoc Duy wrote:
> 
>         > On 5/29/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
>         > > pointy..clicky..pointy..clicky  (aka: cp gitk git-k)
>         > >
>         > > $ git k
>         > >
>         > > :)
>         >
>         > Maybe we should teach git.c to try gitk if git-k is not found ;)
> 
>         Something like this?
> 
> +static int cmd_gitk(int argc, const char **argv, const char *prefix)
> +{
> +       return execv("gitk", (char *const *)argv);
> +}
> +

This does not work. Windows's execv() does not know how to invoke shell
(or tcl) scripts. Only execve() does, because we have our own
implementation.

I'd prefer to install gitk under both names gitk and git-k (as hard
links; which would amount to copies on Windows, but we don't care).

-- Hannes

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Johannes Sixt escreveu:
>> I'd suggest create a small C wrapper to launch gitk. It would be much
>> easier that way IMHO.
> 
> Doh! You're right! It's even there already, right before our eyes:
> 
> pointy..clicky..pointy..clicky  (aka: cp gitk git-k)
> 
> $ git k
> 
> :)

how about 

  git tk 

that's more in line what actually happens. We can ship a gitk.bat
that runs git-tk.

BTW, I got one report that gitk doesn't work with the tcl/tk that I
ship.  Can I have other reports too? ie. 

  "It doesn't work for me, I use windows 92" 
  "It works for me, I use windows QZ" 

etc.?
-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Johannes Schindelin]

Hi,

On Tue, 29 May 2007, Han-Wen Nienhuys wrote:

> Johannes Sixt escreveu:
> >> I'd suggest create a small C wrapper to launch gitk. It would be much
> >> easier that way IMHO.
> > 
> > Doh! You're right! It's even there already, right before our eyes:
> > 
> > pointy..clicky..pointy..clicky  (aka: cp gitk git-k)
> > 
> > $ git k
> > 
> > :)
> 
> how about 
> 
>   git tk 
> 
> that's more in line what actually happens. We can ship a gitk.bat
> that runs git-tk.
> 
> BTW, I got one report that gitk doesn't work with the tcl/tk that I
> ship.  Can I have other reports too? ie. 
> 
>   "It doesn't work for me, I use windows 92" 

It worked for me, using Windows XP. (But I don't remember if I had to do 
some adjustments for it, or only for git-gui.)

BTW Almost any operation I run in git-gui fails, because cat is not found.

Ciao,
Dscho

Re: GIT on MinGW problem

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 
> BTW Almost any operation I run in git-gui fails, because cat is
> not found.

That's the stuff that goes into a console and dumps both to
stdout and stderr.  E.g. fetch, push, "compress database".

The issue is Tcl doesn't give me a way to get a pipe to both stdout
and stderr.  I cannot get two pipes, nor can I get a single pipe
with both stdout+stderr redirected to that pipe.  Unless I pipe
it into another process.  Enter `cat`.

Would we consider a "--stderr-to-stdout" long option to git itself?
Then I could have git-gui do:

	git --stderr-to-stdout fetch

and bypass the pipe into cat.  Yes, I know, its crap.  Welcome to
Tcl.

-- 
Shawn.

[PATCH] Git wrapper: add --redirect-stderr option

[Johannes Schindelin]

With this option, stderr is redirected to stdout. The short option is '-2'.

Alternatively, you can say '--redirect-stderr=<filename>' to redirect
stderr to a file.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Tue, 29 May 2007, Shawn O. Pearce wrote:

	> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
	> > 
	> > BTW Almost any operation I run in git-gui fails, because cat 
	> > is not found.
	> 
	> That's the stuff that goes into a console and dumps both to
	> stdout and stderr.  E.g. fetch, push, "compress database".
	> 
	> The issue is Tcl doesn't give me a way to get a pipe to both 
	> stdout and stderr.  I cannot get two pipes, nor can I get a 
	> single pipe with both stdout+stderr redirected to that pipe.  
	> Unless I pipe it into another process.  Enter `cat`.
	> 
	> Would we consider a "--stderr-to-stdout" long option to git 
	> itself? Then I could have git-gui do:
	> 
	> 	git --stderr-to-stdout fetch
	> 
	> and bypass the pipe into cat.  Yes, I know, its crap.  Welcome 
	> to Tcl.

	How about this?

 git.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/git.c b/git.c
index 53d81e9..72e0539 100644
--- a/git.c
+++ b/git.c
@@ -82,6 +82,20 @@ static int handle_options(const char*** argv, int* argc)
 		} else if (!strcmp(cmd, "--bare")) {
 			static char git_dir[PATH_MAX+1];
 			setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 1);
+		} else if (!strcmp(cmd, "-2") ||
+				!strcmp(cmd, "--redirect-stderr")) {
+			if (dup2(1, 2) < 0)
+				return error("Could not redirect stderr: %s",
+					strerror(errno));
+		} else if (!prefixcmp(cmd, "--redirect-stderr=")) {
+			int fd = open(cmd + 18, O_WRONLY | O_CREAT, 0777), ret;
+			if (fd < 0)
+				return error("Could not open %s", cmd + 18);
+			ret = dup2(fd, 2);
+			close(fd);
+			if (ret < 0)
+				return error("Could not redirect stderr: %s",
+					strerror(errno));
 		} else {
 			fprintf(stderr, "Unknown option: %s\n", cmd);
 			usage(git_usage_string);
-- 
1.5.2.2642.gc8bae-dirty

Re: [PATCH] Git wrapper: add --redirect-stderr option

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 
> With this option, stderr is redirected to stdout. The short option is '-2'.
> 
> Alternatively, you can say '--redirect-stderr=<filename>' to redirect
> stderr to a file.

Yes, that works nicely.  ;-)

Now here's my other problem: How does git-gui know the underlying
git will accept --redirect-stderr?  Or that it supports any other
recent features we've developed?

Sure I can check the version, but until I know what version of Git
its shipping in I cannot put the check into git-gui.

I was thinking about adding a "git-supported-features" plumbing
command that prints back feature code strings, much as our
network protocol supplies back the few feature codes it supports
("multi-ack", "sideband", etc.).  E.g.:

  $ git supported-features
  redirect-stderr
  ...

That way higher level Porcelain can poll the plumbing to see what
is available, and what isn't.

-- 
Shawn.

Re: [PATCH] Git wrapper: add --redirect-stderr option

[Johannes Schindelin]

Hi,

On Tue, 29 May 2007, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > 
> > With this option, stderr is redirected to stdout. The short option is '-2'.
> > 
> > Alternatively, you can say '--redirect-stderr=<filename>' to redirect
> > stderr to a file.
> 
> Yes, that works nicely.  ;-)
> 
> Now here's my other problem: How does git-gui know the underlying
> git will accept --redirect-stderr?  Or that it supports any other
> recent features we've developed?

I thought that git-gui is now really closely coupled with core-git.

> Sure I can check the version, but until I know what version of Git
> its shipping in I cannot put the check into git-gui.
> 
> I was thinking about adding a "git-supported-features" plumbing
> command that prints back feature code strings, much as our
> network protocol supplies back the few feature codes it supports
> ("multi-ack", "sideband", etc.).

Problem is: it would be more interesting to have this program in _older_ 
versions... ;-)

Ciao,
Dscho

Re: [PATCH] Git wrapper: add --redirect-stderr option

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 
> On Tue, 29 May 2007, Shawn O. Pearce wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > 
> > > With this option, stderr is redirected to stdout. The short option is '-2'.
> > > 
> > > Alternatively, you can say '--redirect-stderr=<filename>' to redirect
> > > stderr to a file.
> > 
> > Yes, that works nicely.  ;-)
> > 
> > Now here's my other problem: How does git-gui know the underlying
> > git will accept --redirect-stderr?  Or that it supports any other
> > recent features we've developed?
> 
> I thought that git-gui is now really closely coupled with core-git.

Not really.  It requires 1.5.0 and later, but after that it should
be OK with any 1.5.x version of Git.  Junio graciously bundles it
with core Git, to help it get a wider audience.  ;-)

However I'd like to let it be smarter about what it expects from the
underling core Git.  I'm sure the other Porcelain authors would also
like to be able to determine if they can rely on something, or not.
At the least we can just tell the user "Your Git old.  Upgrade to new
Git today!".  Yes, bad Engrish included... ;-)
 
> > Sure I can check the version, but until I know what version of Git
> > its shipping in I cannot put the check into git-gui.
> > 
> > I was thinking about adding a "git-supported-features" plumbing
> > command that prints back feature code strings, much as our
> > network protocol supplies back the few feature codes it supports
> > ("multi-ack", "sideband", etc.).
> 
> Problem is: it would be more interesting to have this program in _older_ 
> versions... ;-)

Lack of git-supported-features means only features before it coming
into existance?  ;-)

-- 
Shawn.

Re: [PATCH] Git wrapper: add --redirect-stderr option

[Johannes Schindelin]

Hi,

On Tue, 29 May 2007, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > 
> > On Tue, 29 May 2007, Shawn O. Pearce wrote:
> > 
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > 
> > > > With this option, stderr is redirected to stdout. The short option is '-2'.
> > > > 
> > > > Alternatively, you can say '--redirect-stderr=<filename>' to redirect
> > > > stderr to a file.
> > > 
> > > Yes, that works nicely.  ;-)
> > > 
> > > Now here's my other problem: How does git-gui know the underlying
> > > git will accept --redirect-stderr?  Or that it supports any other
> > > recent features we've developed?
> > 
> > I thought that git-gui is now really closely coupled with core-git.
> 
> Not really.  It requires 1.5.0 and later, but after that it should
> be OK with any 1.5.x version of Git.  Junio graciously bundles it
> with core Git, to help it get a wider audience.  ;-)
> 
> However I'd like to let it be smarter about what it expects from the
> underling core Git.  I'm sure the other Porcelain authors would also
> like to be able to determine if they can rely on something, or not.
> At the least we can just tell the user "Your Git old.  Upgrade to new
> Git today!".  Yes, bad Engrish included... ;-)

When in doubt, you can always test the return value to check if the 
command line option is accepted...

Ciao,
Dscho

Re: GIT on MinGW problem

[Aaron Gray]

>This should be fixed in
>
>http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe

Great.

I could not get commands like git-clone to work from CMD although this is 
not really a handycap for the time being.

On doing a clone I get the message :-

        warning: templates not found /usr/share/git-core/templates/

Aaron 

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

I think it might be a bug. Patches are welcome.

I suppose git-clone has a hardcoded path. Paths under windows should
be either taken from registry (yuck) or dynamically detected from
$PATH and argv[0].

2007/5/15, Aaron Gray <angray@beeb.net>:
> Han-Wen,
>
> Dont know whether you got the message or not so I'll try you again.
>
> On doing a git-clone I get the message :-
>
>         warning: templates not found /usr/share/git-core/templates/
>
> Regards,
>
> Aaron
>
> > >This should be fixed in
> >>
> >>http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe
> >
> > Great.
> >
> > I could not get commands like git-clone to work from CMD although this is
> > not really a handycap for the time being.
> >
> > On doing a clone I get the message :-
> >
> >        warning: templates not found /usr/share/git-core/templates/
>
>


-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT on MinGW problem

[Johannes Sixt]

Han-Wen Nienhuys wrote:
> 
> I think it might be a bug. Patches are welcome.
> 
> I suppose git-clone has a hardcoded path. Paths under windows should
> be either taken from registry (yuck) or dynamically detected from
> $PATH and argv[0].
> 
> 2007/5/15, Aaron Gray <angray@beeb.net>:
> > Han-Wen,
> >
> > Dont know whether you got the message or not so I'll try you again.
> >
> > On doing a git-clone I get the message :-
> >
> >         warning: templates not found /usr/share/git-core/templates/
> >

This should have been fixed by 2d84ffaf (currently master~1 in
git://repo.or.cz/git/mingw.git) and its parent. Can you make sure that
your build picks up the new Makefile setting that these commits
introduce?

-- Hannes

Re: GIT on MinGW problem

[Nguyen Thai Ngoc Duy]

On 5/16/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Han-Wen Nienhuys wrote:
> >
> > I think it might be a bug. Patches are welcome.
> >
> > I suppose git-clone has a hardcoded path. Paths under windows should
> > be either taken from registry (yuck) or dynamically detected from
> > $PATH and argv[0].
> >
> > 2007/5/15, Aaron Gray <angray@beeb.net>:
> > > Han-Wen,
> > >
> > > Dont know whether you got the message or not so I'll try you again.
> > >
> > > On doing a git-clone I get the message :-
> > >
> > >         warning: templates not found /usr/share/git-core/templates/
> > >
>
> This should have been fixed by 2d84ffaf (currently master~1 in
> git://repo.or.cz/git/mingw.git) and its parent. Can you make sure that
> your build picks up the new Makefile setting that these commits
> introduce?

That commit didn't work for me because template_dir was overridden by
config.mak.autogen
-- 
Duy

Re: GIT on MinGW problem

[Han-Wen Nienhuys]

Nguyen Thai Ngoc Duy escreveu:
>> > >         warning: templates not found /usr/share/git-core/templates/
>> > >
>>
>> This should have been fixed by 2d84ffaf (currently master~1 in
>> git://repo.or.cz/git/mingw.git) and its parent. Can you make sure that
>> your build picks up the new Makefile setting that these commits
>> introduce?
> 
> That commit didn't work for me because template_dir was overridden by
> config.mak.autogen

thanks for noticing this. I'm building a -2 release which should fix this.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen