Git for Windows Release Notes (Git-1.7.4-preview20110204)
Last update: 4 February 2011
Introduction
These release notes describe issues specific to the Git for Windows
release.
General release notes covering the history of the core git commands are
included in the subdirectory doc/git/html of the installation
directory. Look for files starting with RelNotes.
Known issues
- Some commands are not yet supported on Windows and excluded from the
installation; namely: git archimport, git cvsexportcommit, git
cvsimport, git cvsserver, git instaweb, git shell.
- The Logitec QuickCam software can cause spurious crashes. See "Why
does make often crash creating a sh.exe.stackdump file when I try to
compile my source code?" on the MinGW Wiki
(http://www.mingw.org/wiki/Environment_issues)
- The Quick Launch icon will only be installed for the user running
setup (typically the Administrator). This is a technical restriction
and will not change.
- curl uses $HOME/_netrc instead of $HOME/.netrc.
- If you want to specify a different location for --upload-pack, you
have to start the absolute path with two slashes. Otherwise MSys will
mangle the path.
- git and bash have serious problems with non-ASCII file names (Issue
80, 159).
- If configured to use plink, you will have to connect with putty first
and accept the host key.
- As merge tools are executed using the MSys bash, options starting with
"/" need to be handled specially: MSys would interpret that as a POSIX
path, so you need to double the slash (Issue 226). Example: instead
of "/base", say "//base". Also, extra care has to be paid to pass
Windows programs Windows paths, as they have no clue about MSys style
POSIX paths -- You can use something like $(cmd //c echo
"$POSIXPATH").
Changes since Git-1.7.3.2-preview20101025
Comes with Git 1.7.4 plus patches.
Includes antiword to enable viewing diffs of .doc files
Includes poppler to enable viewing diffs of .pdf files
Removes cygwin paths from the bash shell PATH
On Sun, 6 Feb 2011, Jon wrote:
> Would you please remove the *preview* text from all of your downloads?
> I understand if you don't want to do it immediately, but how about for
> your next release?
No. It sends the wrong signal: it would make people believe that it is
actually okay to rely on msysGit on a daily basis and not get involved in
fixing bugs.
Not that the "-preview" suffix and the "alpha" status would prevent all
kinds of jokers from complaining publically about the brokenness of Git
for Windows instead of fixing their pet peeves like grown-ups do.
Or for that matter: the status does not prevent companies from using Git
for Windows and not contributing anything back (such as hosting a nice
event for all those who did the actual work).
So: no, I am completely opposed to removing that suffix, and will continue
to do so unless things change substantially.
Hth,
Johannes
I have a 180 degree different POV. The preview label does nothing to entice people to get involved and fix bugs.
The fact is (in my world view) that there's only a subset of your users who are passionate _and_ experienced enough to actually fix bugs. The rest of us are just happy (and hopefully grateful) users who _might_ report bugs. For the few bug fixers that matter, I suspect they could care less what you name the downloads.
I'm not going to start an argument with you over POV or style. Bottom line, you and the other contributors are doing great work on msyGit, and well, I'm just a happy user who uses it on a daily basis who believes the time for the preview label has passed.
I simply want to advocate for a re-think on how you name things as I see the current naming working against all the good that you folks are doing. There's crappier software out there _not_ using the preview label.
Perhaps this is cultural, perhaps not. However, I think there are a subset of folks who think "Well, if the developers themselves think it's only 'preview' quality, they must be right. I'm going to wait until it stabilizes."
My instigating is done and no more from me on this thread ;)
Thank you again -- and the rest of the team -- for the fantastic tool and continued support.
Jon
---
blog: http://jonforums.github.com/
twitter: @jonforums