Re: MinGW binary installer available

Previous thread: Why are commits on detached heads good, again? by linux on Wednesday, February 7, 2007 - 7:26 am. (3 messages)

Next thread: Debian X.org team moves to git by Andy Parkins on Wednesday, February 7, 2007 - 8:27 am. (1 message)
From: Han-Wen Nienhuys
Date: Wednesday, February 7, 2007 - 7:38 am

Hi, 

I had a try to see whether I could make GUB
also produce a MinGW installer for Git.

You can download the result at 

http://lilypond.org/mingit/mingit-1.4.9993-1.mingw.exe

the odd version number was because I was too lazy to write code
to extract the version number from the repository automatically.

I don't actually have a windows copy, so it's basically untested.
However, I did succeed in running rev-list in wine.


PS. I'd be interested in comments on using GUB from others.
GUB is a cross-compiling build tool, probably best described
as a "Poor Man's Conary".
 
Once I have the boilerplate code committed, building this 
installer should amount to  

  darcs get  http://lilypond.org/vc/gub.darcs/ gub
  cd gub
  make -f Makefile.mingit bootstrap mingw

(yes, GUB itself is still hosted in Darcs. Shoot me.)


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

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

From: Johannes Schindelin
Date: Wednesday, February 7, 2007 - 7:55 am

Hi,



I played a little with it. IMHO it makes no sense to use it without a 
bash, and without less. For example,

	$ git init
	$ git add git.exe
	$ git status
	$ git commit -a -m initial
	$ git show HEAD

do not produce any output when issued in cmd.

Also, many scripts rely on bash and/or perl, so you'd have to include 


I will.

Ciao,
Dscho

-

From: Johannes Schindelin
Date: Wednesday, February 7, 2007 - 8:05 am

Hi,


Side note: Since "ln <src> <dest>" in MinGW is really a copy, not a hard 
link, this gets rather big (44M here).

Which makes me think if we should just disallow the "git-<builtin>" on 
Windows, since sooner or later, Git will no longer be used from the 
command line on Windows.

And another thing hit me there: Are you sure that all works well if you 
change the install path from "C:\Program Files\Git" to something else?
Without explicitely setting GIT_EXEC_PATH?

Ciao,
Dscho

-

From: Han-Wen Nienhuys
Date: Wednesday, February 7, 2007 - 8:14 am

I have no idea. The installer just plonks the files into C:/P F/Git/
and adds that to $INSTALLDIR/usr/bin/ to $PATH


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

From: Han-Wen Nienhuys
Date: Wednesday, February 7, 2007 - 8:08 am

Indeed: for now, this is intended for people clueful enough to install
bash and perl on their own.  Adding bash itself should be easy, but
I have no idea how to make cmd open the scripts with bash automatically.

The thought of x-compiling perl makes me shudder. 

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

From: Johannes Schindelin
Date: Wednesday, February 7, 2007 - 8:26 am

Hi,


Would be nice to include them, though. In this case, you can add a 

You don't want to tell me that you x-compile Python when bundling 
LilyPond, do you?

Ciao,
Dscho

-

From: Han-Wen Nienhuys
Date: Wednesday, February 7, 2007 - 8:34 am

See

  http://lilypond.org/vc/gub.darcs/patches/python-2.5.patch
  https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group...

I freely admit that it doesn't work very well, because the python build 
procedure is rather naive when it comes to detecting installed modules.

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

From: Johannes Schindelin
Date: Wednesday, February 7, 2007 - 9:16 am

Hi,


So you _do_ build it? Phew.

A few months back, when we had that nasty Aussie on lily-devel whining 
about not being able to compile LilyPond on Windows, I tried to build 
_all_ of the dependencies on MinGW, including Python. Needless to say, I 
gave up...

BTW do you have side branches in that darcs gub repository? If not, I'll 
try to leech it into a git repo with tailor (I do not want to install 
darcs on all my machines, just to play with gub).

Ciao,
Dscho

-

From: Han-Wen Nienhuys
Date: Wednesday, February 7, 2007 - 10:05 am

No, but I have a conversion running here.  I'll publish it once it's done.

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

From: Johannes Schindelin
Date: Wednesday, February 7, 2007 - 10:10 am

Hi,


Thank you very much!

Just out of curiosity: What do you use to convert it? Tailor all branches, 
then stitch them together? (With tailor, stitching is possible as long as 
you did not merge branches: the commit objects _will_ be identical, since 
even the commit timestamps are derived from the source repository.)

Ciao,
Dscho

-

From: Han-Wen Nienhuys
Date: Wednesday, February 7, 2007 - 10:35 am

A simple linear import of all the patches. Since Darcs
uses patch based storage, I think it's not possible to accurately map a Darcs
repository onto a Git one without creating branch spaghetti. 

I have never grokked how tailor is supposed to work, so I use a home made
script.

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

From: Han-Wen Nienhuys
Date: Wednesday, February 7, 2007 - 2:10 pm

That was spoken with hybris.  Bash uses a regular gnu autoconf build
procedure, so making it build is much less of a pain to than massaging eg.
Python. However, it is a unix shell, and as such it does fork() all
the time. Hence, it is necessary to use Cygwin (or its derivative MSYS)
for running Bash.

A good reason to get rid of bash scripts.

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

From: Han-Wen Nienhuys
Date: Wednesday, February 7, 2007 - 9:03 am

Strange, those are builtins, not?  I recall that we also had
some issues with lilypond stdout printing things inside CMD,
depending on whether -mwindows is on the link line.
Details escape me, though. 

Jan? 

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

From: Jan Nieuwenhuizen
Date: Wednesday, February 7, 2007 - 1:18 pm

I didn't either, but Google says

   This is a windows limitation.  GUI apps (apps created with -mwindows)
   can't send output to or receive input from the console.

That seems right, I remember that we chose to use -mwindows to get
rid of the flashing black console silliness.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org
-

From: Han-Wen Nienhuys
Date: Wednesday, February 7, 2007 - 2:21 pm

Can you confirm to me that these do actually work? 

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

From: Johannes Schindelin
Date: Wednesday, February 7, 2007 - 4:51 pm

Hi,


Apart from commit, which is a shell script, they appear to work. Only no 
uoutput :-)

Ciao,
Dscho

-

From: Han-Wen Nienhuys
Date: Wednesday, February 7, 2007 - 3:10 pm

can you check out the -2 build, at 
 
  http://lilypond.org/git/binaries/mingw/git-1.4.9993-2.mingw.exe
  
to see if this is better?

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

From: Johannes Schindelin
Date: Wednesday, February 7, 2007 - 4:52 pm

Hi,


Unfortunately, today was the last day for me at a company where I have 
access to Losedows. I'll try to get hold of another machine, and try 
there, though.

Ciao,
Dscho

-

From: Jan Nieuwenhuizen
Date: Thursday, February 8, 2007 - 12:58 pm

Yes, much better.  There's still the bash script problem, maybe
these should be replaced with python?

$ ./git-1.4.9993-2.mingw.exe /S
20:48:11 root@Abbicci:~
$ PATH=/cygdrive/c/Program\ Files/Git/usr/bin/:$PATH
20:48:46 root@Abbicci:~
$ which git
/cygdrive/c/Program Files/Git/usr/bin/git
20:48:49 root@Abbicci:~
$ mkdir -p vc/test.git
20:49:03 root@Abbicci:~
$ cd vc/test.git/
20:49:05 root@Abbicci:~/vc/test.git
$ git init 
Initialized empty Git repository in .git/
warning: templates not found /usr/share/git-core/templates/
20:52:31 root@Abbicci:~/vc/test.git
$ git status
git: 'status' is not a git-command

The most commonly used git commands are:
    add            Add file contents to the changeset to be committed next
    apply          Apply a patch on a git index file and a working tree
    archive        Creates an archive of files from a named tree
    bisect         Find the change that introduced a bug by binary search
    branch         List, create, or delete branches
    checkout       Checkout and switch to a branch
    cherry-pick    Apply the change introduced by an existing commit
    clone          Clones a repository into a new directory
    commit         Record changes to the repository
    diff           Show changes between commits, commit and working tree, etc
    fetch          Download objects and refs from another repository
    grep           Print lines matching a pattern
    init           Create an empty git repository or reinitialize an existing one
    log            Show commit logs
    merge          Join two or more development histories together
    mv             Move or rename a file, a directory, or a symlink
    prune          Prunes all unreachable objects from the object database
    pull           Fetch from and merge with another repository or a local branch
    push           Update remote refs along with associated objects
    rebase         Forward-port local commits to the updated upstream head
    reset          Reset ...
From: Johannes Schindelin
Date: Thursday, February 8, 2007 - 1:08 pm

Hi,


Hahahaha!

This is not meant as laughing _about_ you... Along with others, I worked 
very hard to get rid of that naughty dependency to Python.

IMHO the best way for Git is to go builtin. It is the only way to 
guarantee portability to many, many platforms without a dependency 
nightmare.

Who knows, maybe Git will run on VMS yet?

Ciao,
Dscho

-

Previous thread: Why are commits on detached heads good, again? by linux on Wednesday, February 7, 2007 - 7:26 am. (3 messages)

Next thread: Debian X.org team moves to git by Andy Parkins on Wednesday, February 7, 2007 - 8:27 am. (1 message)