Re: What's the status of MinGW port.

Re: What's the status of MinGW port.

[dhruva]

Hi,
 I cloned the git repo from 'git://git2.kernel.org/pub/scm/git/git.git'. I had an earlier msysGIT with build environment. I just got into the msys (bash) environment and ran a 'gmake'. It built fine on Windows XP.
 I thank everyone involved in making git work on windoze. It really makes it a lot more easier to push git as a serious dVCS in the corporate world with development hapenning on different platforms :-)
 Once I iron out git-p4, hoping to say "Git the hell out of here ... p4" soon.

A trivial issue in install:
'gmake install' had a small issue in trying to install non existant 'git-shell.exe'. The following trivial patch on master to Makefile handles that:


diff --git a/Makefile b/Makefile
index dfed7ba..d5a3327 100644
--- a/Makefile
+++ b/Makefile
@@ -1365,7 +1365,10 @@ install: all
        $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
        $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
        $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
-       $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive
$X git-shell$X '$(DESTDIR_SQ)$(bindir_SQ)'
+ifndef NO_POSIX_ONLY_PROGRAMS
+       $(INSTALL) git-shell$X '$(DESTDIR_SQ)$(bindir_SQ)'
+endif
+       $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive
$X '$(DESTDIR_SQ)$(bindir_SQ)'
        $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
        $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
 ifndef NO_TCLTK


-dhruva


----- Original Message ----
> From: Johannes Sixt <j.sixt@viscovery.net>
> To: Kevin Yu <yujie052@gmail.com>
> Cc: git@vger.kernel.org
> Sent: Monday, 8 September, 2008 12:38:08 PM
> Subject: Re: What's the status of MinGW port.
> 
> Kevin Yu schrieb:
> >       GIT is a great tool, but I'm running Windows XP.
> >       It seems like msysgit hasn't been updated for a long time,
> > neither has the mingw.git branch.
> >       Is there any plan to create a native version of GIT on MS Windows?
> 
> There are no plans anymore to create such a thing.
> 
> It is already there: http://code.google.com/p/msysgit/
> 
> If the lack of activity is worrysome to you, you could help create a
> release tarball for 1.6..0(.x).
> 
> -- Hannes
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



      Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address

[PATCH] Windows: git-shell can be compiled again

[Johannes Sixt]

From: Johannes Sixt <johannes.sixt@telecom.at>

The reason that git-shell was excluded from the Windows build was that
our compatibility layer needed stuff that was removed when we tried to
link less of the git library into git-shell. Since 4cfc24afc9ff the
complete library is linked again, so we can build git-shell on Windows
as well. (This fixes 'make install', which depends on that git-shell
is always built.)

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
dhruva schrieb:
>  I cloned the git repo from 'git://git2.kernel.org/pub/scm/git/git.git'.
> I had an earlier msysGIT with build environment. I just got into the msys
> (bash) environment and ran a 'gmake'. It built fine on Windows XP.

This is good to know.

> A trivial issue in install:
> 'gmake install' had a small issue in trying to install non existant
> 'git-shell.exe'. The following trivial patch on master to Makefile
> handles that:

Thanks for bringing up the issue. I was a bit careless reviewing the
changes in that area. Here is a better fix.

-- Hannes

 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index dfed7ba..37575f4 100644
--- a/Makefile
+++ b/Makefile
@@ -296,6 +296,7 @@ PROGRAMS += git-pack-redundant$X
 PROGRAMS += git-patch-id$X
 PROGRAMS += git-receive-pack$X
 PROGRAMS += git-send-pack$X
+PROGRAMS += git-shell$X
 PROGRAMS += git-show-index$X
 PROGRAMS += git-unpack-file$X
 PROGRAMS += git-update-server-info$X
@@ -834,7 +835,6 @@ EXTLIBS += -lz
 ifndef NO_POSIX_ONLY_PROGRAMS
 	PROGRAMS += git-daemon$X
 	PROGRAMS += git-imap-send$X
-	PROGRAMS += git-shell$X
 endif
 ifndef NO_OPENSSL
 	OPENSSL_LIBSSL = -lssl
-- 
1.6.0.1.1208.g0bd3.dirty

Re: [PATCH] Windows: git-shell can be compiled again

[dhruva]

Hi,
 Are there any M$ specific issues still out there that needs some attention? I could help on stuff that does not require git internal knowledge. Are there some M$ specific performance issues that I could try to help? Let me know, I will try my best to help. I need to have git on both GNU/linux and M$ platforms for day job.

-dhruva



      Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address

Re: [PATCH] Windows: git-shell can be compiled again

[Johannes Sixt]

dhruva schrieb:
>  Are there any M$ specific issues still out there that needs some attention? I could help on stuff that does not require git internal knowledge. Are there some M$ specific performance issues that I could try to help? Let me know, I will try my best to help. I need to have git on both GNU/linux and M$ platforms for day job.

In order of increasing difficulty:

- Run the tests on different platforms and servicepack levels.

- Get proficient in building the installer for a release.

- Find a way to build perl scripts that is acceptable for upstream git.git
and that also works on MSYS/MinGW. Currently we still modify the build
procedure, and the results do not work during 'make test'.

- Give some love to git-svn.perl. It will be removed from msysgit's
1.6.0.x release because it raises expectations that cannot be fulfilled.
Please dig the list archive: http://groups.google.com/group/msysgit

I don't think a lot can be done performance-wise unless you want to help
port scripts to C.

-- Hannes

Re: [PATCH] Windows: git-shell can be compiled again

[dhruva]

Hi,



----- Original Message ----
> From: Johannes Sixt <j.sixt@viscovery.net>
> In order of increasing difficulty:
> 
> - Run the tests on different platforms and servicepack levels.

I have no access to multiple boxes but when more people start using git locally, I will try that.
 
> - Find a way to build perl scripts that is acceptable for upstream git.git
> and that also works on MSYS/MinGW. Currently we still modify the build
> procedure, and the results do not work during 'make test'.

Could you please elaborate on the above. Do you mean, rewrite some perl scripts or something else?
 
> - Give some love to git-svn.perl. It will be removed from msysgit's
> 1.6.0.x release because it raises expectations that cannot be fulfilled.

Since I do not work on SVN, that would be tough in the present state for me. SVN does not even ship their perl bindings for perl 5.10 and I just could not build it from source. I was considering hacking 'svk' to bring back p4 support (which has been dropped in its current avatar).

> Please dig the list archive: http://groups.google.com/group/msysgit

I will look into it.
 
> I don't think a lot can be done performance-wise unless you want to help
> port scripts to C.

No promises here as I do not know the complexity of perl scripts.

-dhruva



      Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address

Re: [PATCH] Windows: git-shell can be compiled again

[Johannes Sixt]

dhruva schrieb:
>> From: Johannes Sixt <j.sixt@viscovery.net>
>> - Find a way to build perl scripts that is acceptable for upstream git.git
>> and that also works on MSYS/MinGW. Currently we still modify the build
>> procedure, and the results do not work during 'make test'.
> 
> Could you please elaborate on the above. Do you mean, rewrite some perl scripts or something else?

No. I mean to have a better solution to the build procedure than commit
bd2f73a6ba6da in mingw.git. Look at that commit and at the 'use ...' line
that the build procedure inserts at the top of the perl scripts, and you
should understand the problem (hint: it's the colon in "C:/somwhere").

-- Hannes