License: GPL v2
Description: MSysGit Portable is the handy Git SCM software and a portable command prompt packaged with a PortableApps.com Launcher as a portable app, so you can check out your source wherever you go.
Download MSysGit Portable 1.6.5 Development Test 1 [11.4MB download / 141MB installed]
Development Test 1 (2010-03-04): Initial release
I'm using the "official" MSysGit Portable package from June (about to upgrade to the Sept. release). It works quite well (though I ended up writing this BAT file to help it with setting HOME properly.
If by chance you're still working on this, it would be great if you could take a look at the latest release of MSysGit, try out packaging it, and update this thread. I'd love a chance to test the two versions (your "fork" and "origin:master" side-by-side.
Meanwhile, I'll see if the 1.7.2 series still has issues with HOME.
please let me know if you're still actively developing this and wish to continue working on it or if I may take over.
I have done some work related, but it is focused on the whole GitExtensions package
(http://code.google.com/p/gitextensions). I have one portable version that actually works. Basically, it works well enough that I have removed installed versions from all my pcs and I am managing my repos completely from my portable app.
Due to obvious .net dependencies, I haven't published anything. But I just found out a forum post related to .net apps, so I will probably post something relevant in the following days.
This is my post to the developers' forum, if you want to check it out:
Hope I'm being usefull.
first of all thanks for your reply
I personally have never used Git Extensions, only regular (msys)git. My question is, is Git Extensions dependent on normal Git? My Package is basically portablegit with customizable launchers.
I don't know about .NET dependencies, but normal git does not have any (afaik).
My suggestion is to publish two separate "Apps", one for regular Git and one for Git Extensions, and make Git Extensions dependent on Git if necessary. This would also allow you to address the .NET issues separately. What do you think about that?
Not sure if this is of any interest, or whether you have tackled all my bugbears already, but I have posted a Development Release of MSYS which I am currently using in my own portable development setup. I am hoping for any advice/comments which may help make this more drive/folder/system independent and robust (for tackling crazily convoluted directory structures for example :)).
Anyway, here it is, and let me know any thoughts you have. Loving the work guys!
MSYS Portable 1.10.11 Development Test 1
as far as i know, msysgit does not really have something to do with msys, except that it's built using mingw and msys
Any thoughts on forking the project on GitHub.
The msysgit devel team may find this extension useful and add it to their development cycle. They already have a portable version so I doubt there are any legal/philosophical issues with incorporating a PA installer.
If you know how to use git+github take a look at the official project here: https://github.com/msysgit/msysgit/network.
If you aren't already using the portable version you can find the download here:
Hi... I just created an online installer for PortableGit. You can find it at https://github.com/jpoul/MSysGitPortable. No bash for now, but take a look. Maybe we can merge this ?
Hope I'm being usefull.
I am hoping that somebody may be able to help. I'm trying to add MinGW Portable and MSYS Portable to my PATH variable using a bash_profile file located in
MSysGitPortable\App\MSYSGit\etc. My problem is that I can't seem to get it to work without using the flash drive letter. For some reason, if I use a relative path, it works only in the MsysGit initiated directory.
Here is my current
/f/is the flash drive letter.
It would also be great if
MSysGitBashPortable.execan move the
bash_profileto the data directory.
Thanks in advance.
If the application has multiple launchers, it should contain files appicon1.ico for the first menu entry and appicon2.ico for the second.