On Feb 3, 2008, at 3:23 AM, Johannes Schindelin wrote:
- The msysgit scheme should be clearly different from the
official
version: We use winrc instead of rc.
Hmm. That does not convince me. If people see that Git-1.5.5-rc3.exe
does not work, and go to [EMAIL PROTECTED], it would not be too
big a
problem for me.
So I'd like them to be named -rcX after the git.git release scheme.
Ok, I think I need to clarify:
The first part contains the official git version numbers, e.g. 1.5.4-
rc4,
and we add our preview tag to get the full version, e.g.
Git-1.5.4-rc4-preview20080121.exe.
Eventually we'll have a stable official git release containing
all the features we want for a stable Windows release, e.g.
1.5.5, and we want to release our first Windows release
candidate. We do not yet want to declare this stable because
people should, for example, verify our modifications to the
installer. In this case I propose to add a *different* rc tag
than the official one to avoid confusion. We would name it for
example Git-1.5.5-winrc0.exe. This means the first Windows
release candidate of the setup installing *stable* git 1.5.5.
It could cause a lot of confusion if we named it Git-1.5.5-rc0.exe.
We could even have combinations of both, e.g. Git-1.5.5-rc3-winrc0.exe.
However I tend to avoid this and would prefer to use preview<DATE> in
this case.
We also add two criteria that should be met before we go stable
- safe CRLF handling.
- handling of case insensitive filesystems.
Right. Those seem to be the biggest problems for Windows users (me
not
being one, I cannot really tell).
Not only Windows. They are big problems if you start to work
in a real cross platform project. Since I started to do so,
I waste a lot of time explaining people how to work around these
issues. They need help on Windows *and* on Linux *and* on Mac OS X.
The help needed comes in various flavor. Windows users have Unix
line endings, Unix users have Windows line endings, some have mixed
line endings. I can't switch branches on my Mac, because a file
rename only changed case and HFS+ is case-insensitive, too. People
start to copy files from Windows to Unix and I need to tell them
over and over again to set core.autocrlf input on Unix and stop
believing the Windows guys alone would cause the trouble...
I really want to see these issues resolved.
Steffen
