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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
Can you confirm to me that these do actually work? -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen -
Hi, Apart from commit, which is a shell script, they appear to work. Only no uoutput :-) Ciao, Dscho -
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 -
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 -
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 ...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 -
