Hello,
I want to use msysgit with tortoisegit in the company that I work for,
but I can't get an approval for msysgit since its version is preview.
What time can its stable version be released?
On Mon, 28 Mar 2011, csh wrote: > I want to use msysgit with tortoisegit in the company that I work for, > but I can't get an approval for msysgit since its version is preview. > What time can its stable version be released?
Git for Windows is free software. You have two options:
1) work on it yourself until it fulfills your quality criteria, or
2) pay somebody to get it there.
Specifically, if your goal is to remove the "-preview" from the package name, you can
1) rename the file, or
2) state more clearly what your company deems stable enough, and hope that somebody gives you an estimate how much it would cost to get it there.
The company I work for has very strict rules. Normally I already use beta software personally. Of course my goal is not to remove "-preview", but our software committee will review everything, and because of the "preview" word on the version number, it may be rejected.
Isn't it possible for msysgit to be released as stable version?
>> I want to use msysgit with tortoisegit in the company that I work for, >> but I can't get an approval for msysgit since its version is preview. >> What time can its stable version be released? > Git for Windows is free software. You have two options:
> 1) work on it yourself until it fulfills your quality criteria, or
> 2) pay somebody to get it there.
> Specifically, if your goal is to remove the "-preview" from the package > name, you can
> 1) rename the file, or
> 2) state more clearly what your company deems stable enough, and hope that > somebody gives you an estimate how much it would cost to get it there.
>> I want to use msysgit with tortoisegit in the company that I work for, >> but I can't get an approval for msysgit since its version is preview. >> What time can its stable version be released?
> Git for Windows is free software. You have two options:
> 1) work on it yourself until it fulfills your quality criteria, or
> 2) pay somebody to get it there.
> Specifically, if your goal is to remove the "-preview" from the package > name, you can
> 1) rename the file, or
> 2) state more clearly what your company deems stable enough, and hope that > somebody gives you an estimate how much it would cost to get it there.
While I agree with what you're saying here, perhaps we should consider losing the "-preview"-suffix anyway? I mean, Git for Windows is the de facto Git distribution for Windows, and I think it's closing in on getting "stable enough" (a very subjective measure, I know). Quite a bit of people seem to be confused by the naming already.
After all, removing the "-preview"-suffix won't make Git for Windows unfree software. People will still have to pay or convince someone to do work for them (unless they're willing to do it themselves), like with most other free software...
If we decide to do this, I'd suggest doing it at the same time as changing the naming for our packages as has been suggested before (if we even end up deciding to do that as well, of course). I'd like to see something like this: Git-1.7.4-preview20110204.exe -> git-1.7.4.exe PortableGit-1.7.4-preview20110204.7z -> git-1.7.4-portable.7z msysGit-fullinstall-1.7.4-preview20110204.exe -> git-1.7.4.3-dev.exe (?)
I'm not so sure about the netinstall; why do we have new releases of the netinstall with every release? Isn't it just cloning the always-up-to-date repo on repo.or.cz? As long as we have tags for every released versions, can't we just maintain one binary? Or is there something I'm missing?
On Mon, Mar 28, 2011 at 7:12 PM, Volkan Orhan <volkan...@gmail.com> wrote: > Hi again,
> The company I work for has very strict rules. Normally I already use beta > software personally. Of course my goal is not to remove "-preview", but our > software committee will review everything, and because of the "preview" word > on the version number, it may be rejected.
> Isn't it possible for msysgit to be released as stable version?
Changing the name won't make Git for Windows more or less stable. All changing the name does is change people's expectations. I think keeping expectations low is the reason we have the prefix in the first place.
If the company you work for care about the name, then they aren't just strict; they are impractical :P Unfortunately, a lot of companies tend to be are just that...
Volkan Orhan <volkan...@gmail.com> wrote: > The company I work for has very strict rules. Normally I already use > beta software personally. Of course my goal is not to remove > "-preview", but our software committee will review everything, and > because of the "preview" word on the version number, it may be > rejected.
> Isn't it possible for msysgit to be released as stable version?
Come on, what do you want -- a mere label on a package or a confidence that it works? If your company is so obsessed with its set of curious rules as to even have a dedicated comittee, make that comittee perform a thorough testing of the feature set your company actually needs. Otherwise it will be mere bureaucracy.
If my point is not clear, look at this: for instance, your company might not want git-svn and so you do not care how broken that part of msysgit can potentially be--you just ignore it. Or consider support for non-ASCII characters in file names, commit messages and system user names: some people just cannot deploy msysgit because of these problems while other people are happily using it because their setups and workflows are unaffected by these problems.
There's no bug-free software, instead, there is software which works OK within the set of particular requirements.
I am a software engineer. I already use msysgit. I presented a git training course to my colleagues (some of them aren't software developer). In my presentation, I taught how to use tortoisegit with msysgit. I requested license for tortoisegit, but when I wanted to request license for msysgit, I saw "preview" word in its version number.
I know that every software has bugs, so I already use beta software (even my linux is beta most of times). But our company will not want everybody to use beta or preview software.
I wanted to compile git stable on msys using mingw, but I got an error related to socklen_t. I didn't try to define it as int since socklen_t should not be depended on the endiannes of the cpu architecture. It is very difficult for me to compile git on msys since there is no bsd sockets library that can be compiled on mingw. In addition, gnulib and glibc also can't be compiled on mingw.
I will be glad so much if "preview" word is removed since it is stable so much (the stable version even may be an old version). It is really very excellent to use git everywhere and every time.
> On Mon, Mar 28, 2011 at 5:53 PM, Johannes Schindelin > <Johannes.Schinde...@gmx.de> wrote: >> Hi,
>> On Mon, 28 Mar 2011, csh wrote:
>>> I want to use msysgit with tortoisegit in the company that I work for, >>> but I can't get an approval for msysgit since its version is preview. >>> What time can its stable version be released? >> Git for Windows is free software. You have two options:
>> 1) work on it yourself until it fulfills your quality criteria, or
>> 2) pay somebody to get it there.
>> Specifically, if your goal is to remove the "-preview" from the package >> name, you can
>> 1) rename the file, or
>> 2) state more clearly what your company deems stable enough, and hope that >> somebody gives you an estimate how much it would cost to get it there.
> While I agree with what you're saying here, perhaps we should consider > losing the "-preview"-suffix anyway? I mean, Git for Windows is the de > facto Git distribution for Windows, and I think it's closing in on > getting "stable enough" (a very subjective measure, I know). Quite a > bit of people seem to be confused by the naming already.
> After all, removing the "-preview"-suffix won't make Git for Windows > unfree software. People will still have to pay or convince someone to > do work for them (unless they're willing to do it themselves), like > with most other free software...
> If we decide to do this, I'd suggest doing it at the same time as > changing the naming for our packages as has been suggested before (if > we even end up deciding to do that as well, of course). I'd like to > see something like this: > Git-1.7.4-preview20110204.exe -> git-1.7.4.exe > PortableGit-1.7.4-preview20110204.7z -> git-1.7.4-portable.7z > msysGit-fullinstall-1.7.4-preview20110204.exe -> git-1.7.4.3-dev.exe (?)
> I'm not so sure about the netinstall; why do we have new releases of > the netinstall with every release? Isn't it just cloning the > always-up-to-date repo on repo.or.cz? As long as we have tags for > every released versions, can't we just maintain one binary? Or is > there something I'm missing?
> On Mon, Mar 28, 2011 at 7:12 PM, Volkan Orhan<volkan...@gmail.com> wrote: >> Hi again,
>> The company I work for has very strict rules. Normally I already use beta >> software personally. Of course my goal is not to remove "-preview", but our >> software committee will review everything, and because of the "preview" word >> on the version number, it may be rejected.
>> Isn't it possible for msysgit to be released as stable version?
> Changing the name won't make Git for Windows more or less stable. All > changing the name does is change people's expectations. I think > keeping expectations low is the reason we have the prefix in the first > place.
> If the company you work for care about the name, then they aren't just > strict; they are impractical :P > Unfortunately, a lot of companies tend to be are just that...
> On Mon, 28 Mar 2011 20:12:45 +0300 > Volkan Orhan<volkan...@gmail.com> wrote:
>> The company I work for has very strict rules. Normally I already use >> beta software personally. Of course my goal is not to remove >> "-preview", but our software committee will review everything, and >> because of the "preview" word on the version number, it may be >> rejected.
>> Isn't it possible for msysgit to be released as stable version? > Come on, what do you want -- a mere label on a package or a confidence > that it works? If your company is so obsessed with its set of curious > rules as to even have a dedicated comittee, make that comittee perform > a thorough testing of the feature set your company actually needs. > Otherwise it will be mere bureaucracy.
> If my point is not clear, look at this: for instance, your company > might not want git-svn and so you do not care how broken that part of > msysgit can potentially be--you just ignore it. Or consider support > for non-ASCII characters in file names, commit messages and system user > names: some people just cannot deploy msysgit because of these problems > while other people are happily using it because their setups and > workflows are unaffected by these problems.
> There's no bug-free software, instead, there is software which works OK > within the set of particular requirements.
In the future, please quote in-line. This makes it much easier for people to follow the discussion.
On Mon, Mar 28, 2011 at 8:06 PM, Volkan Orhan <volkan...@gmail.com> wrote: > I am a software engineer. I already use msysgit. I presented a git training > course to my colleagues (some of them aren't software developer). In my > presentation, I taught how to use tortoisegit with msysgit. I requested > license for tortoisegit, but when I wanted to request license for msysgit, I > saw "preview" word in its version number.
Ah, you want commercial support? Unfortunately, I'm not aware of anyone who provides that for Git for Windows...
> I know that every software has bugs, so I already use beta software (even my > linux is beta most of times). But our company will not want everybody to use > beta or preview software.
> I wanted to compile git stable on msys using mingw,
What do you mean by "git stable"? The code from git-scm.com (or git.kernel.org)? That's no more stable than Git for Windows. In fact, git-scm.com redirects to the msysGit project for Windows...
> but I got an error > related to socklen_t. I didn't try to define it as int since socklen_t > should not be depended on the endiannes of the cpu architecture. It is very > difficult for me to compile git on msys since there is no bsd sockets > library that can be compiled on mingw. In addition, gnulib and glibc also > can't be compiled on mingw.
Even upstream-git has socklen_t defined for MinGW in compat/mingw.h, that should be used automatically. How exactly are you trying to build Git?
> I will be glad so much if "preview" word is removed since it is stable so > much (the stable version even may be an old version). It is really very > excellent to use git everywhere and every time.
This part I tend to agree with you on. I don't think we need to say that we're a preview version anymore. Git for Windows works very well for me, at least. Much better than any other non-preview version control system I've ever used ;)
> In the future, please quote in-line. This makes it much easier for > people to follow the discussion.
> On Mon, Mar 28, 2011 at 8:06 PM, Volkan Orhan<volkan...@gmail.com> wrote: >> I am a software engineer. I already use msysgit. I presented a git training >> course to my colleagues (some of them aren't software developer). In my >> presentation, I taught how to use tortoisegit with msysgit. I requested >> license for tortoisegit, but when I wanted to request license for msysgit, I >> saw "preview" word in its version number.
> Ah, you want commercial support? Unfortunately, I'm not aware of > anyone who provides that for Git for Windows...
I didn't mean commercial support for now. The license I mean is internal license (allowance) of our company.
>> I know that every software has bugs, so I already use beta software (even my >> linux is beta most of times). But our company will not want everybody to use >> beta or preview software.
>> I wanted to compile git stable on msys using mingw, > What do you mean by "git stable"? The code from git-scm.com (or > git.kernel.org)? That's no more stable than Git for Windows. In fact, > git-scm.com redirects to the msysGit project for Windows...
I downloaded git source codes from git-scm.com Of course msysgit is more stable on Windows, but I wanted to document its version as stable because of rules.
>> but I got an error >> related to socklen_t. I didn't try to define it as int since socklen_t >> should not be depended on the endiannes of the cpu architecture. It is very >> difficult for me to compile git on msys since there is no bsd sockets >> library that can be compiled on mingw. In addition, gnulib and glibc also >> can't be compiled on mingw.
> Even upstream-git has socklen_t defined for MinGW in compat/mingw.h, > that should be used automatically. How exactly are you trying to build > Git?
I downloaded git-1.7.4.1, then run ./configure script on msys. I got the error below:
configure: CHECKS for typedefs, structures, and compiler characteristics checking for socklen_t... no checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t
>> I will be glad so much if "preview" word is removed since it is stable so >> much (the stable version even may be an old version). It is really very >> excellent to use git everywhere and every time.
> This part I tend to agree with you on. I don't think we need to say > that we're a preview version anymore. Git for Windows works very well > for me, at least. Much better than any other non-preview version > control system I've ever used ;)
I agree with you, but there are rules on our company. If the preview word is not removed for a long time, I will try to ask our company to accept preview version.
On Mon, Mar 28, 2011 at 8:58 PM, Volkan Orhan <volkan...@gmail.com> wrote: > On 3/28/2011 9:42 PM, Erik Faye-Lund wrote:
>> In the future, please quote in-line. This makes it much easier for >> people to follow the discussion.
>> On Mon, Mar 28, 2011 at 8:06 PM, Volkan Orhan<volkan...@gmail.com> wrote:
>>> I am a software engineer. I already use msysgit. I presented a git >>> training >>> course to my colleagues (some of them aren't software developer). In my >>> presentation, I taught how to use tortoisegit with msysgit. I requested >>> license for tortoisegit, but when I wanted to request license for >>> msysgit, I >>> saw "preview" word in its version number.
>> Ah, you want commercial support? Unfortunately, I'm not aware of >> anyone who provides that for Git for Windows...
> I didn't mean commercial support for now. The license I mean is internal > license (allowance) of our company.
>>> I know that every software has bugs, so I already use beta software (even >>> my >>> linux is beta most of times). But our company will not want everybody to >>> use >>> beta or preview software.
>>> I wanted to compile git stable on msys using mingw,
>> What do you mean by "git stable"? The code from git-scm.com (or >> git.kernel.org)? That's no more stable than Git for Windows. In fact, >> git-scm.com redirects to the msysGit project for Windows...
> I downloaded git source codes from git-scm.com > Of course msysgit is more stable on Windows, but I wanted to document its > version as stable because of rules.
Aha, if you can somehow prove that msysGit is more stable than upstream on Windows, then perhaps that is enough to get allowance?
>>> but I got an error >>> related to socklen_t. I didn't try to define it as int since socklen_t >>> should not be depended on the endiannes of the cpu architecture. It is >>> very >>> difficult for me to compile git on msys since there is no bsd sockets >>> library that can be compiled on mingw. In addition, gnulib and glibc also >>> can't be compiled on mingw.
>> Even upstream-git has socklen_t defined for MinGW in compat/mingw.h, >> that should be used automatically. How exactly are you trying to build >> Git?
> I downloaded git-1.7.4.1, then run ./configure script on msys. I got the > error below:
> configure: CHECKS for typedefs, structures, and compiler characteristics > checking for socklen_t... no > checking for socklen_t equivalent... configure: error: Cannot find a type to > use > in place of socklen_t
Aha. You don't need to run "./configure", it's only intended for exotic Unices. Just run "make" (but be sure that you have no config.mak.autogen left over from configure), and it should pick up that you're building for MinGW from running uname.
>>> I will be glad so much if "preview" word is removed since it is stable so >>> much (the stable version even may be an old version). It is really very >>> excellent to use git everywhere and every time.
>> This part I tend to agree with you on. I don't think we need to say >> that we're a preview version anymore. Git for Windows works very well >> for me, at least. Much better than any other non-preview version >> control system I've ever used ;)
> I agree with you, but there are rules on our company. If the preview word is > not removed for a long time, I will try to ask our company to accept preview > version.
I suspect that you'll have to go that path, but let's see if more people agrees with us first.
Of course, if your company would be willing to invest some development time into Git for Windows, that'd be a very effective way of getting a stable release ;)
> On Mon, Mar 28, 2011 at 8:58 PM, Volkan Orhan <volkan...@gmail.com> wrote: >> On 3/28/2011 9:42 PM, Erik Faye-Lund wrote:
>>> In the future, please quote in-line. This makes it much easier for >>> people to follow the discussion.
>>> On Mon, Mar 28, 2011 at 8:06 PM, Volkan Orhan<volkan...@gmail.com> wrote:
>>>> I am a software engineer. I already use msysgit. I presented a git >>>> training >>>> course to my colleagues (some of them aren't software developer). In my >>>> presentation, I taught how to use tortoisegit with msysgit. I requested >>>> license for tortoisegit, but when I wanted to request license for >>>> msysgit, I >>>> saw "preview" word in its version number.
>>> Ah, you want commercial support? Unfortunately, I'm not aware of >>> anyone who provides that for Git for Windows...
>> I didn't mean commercial support for now. The license I mean is internal >> license (allowance) of our company.
> Aha, thanks for clarifying.
>>>> I know that every software has bugs, so I already use beta software (even >>>> my >>>> linux is beta most of times). But our company will not want everybody to >>>> use >>>> beta or preview software.
>>>> I wanted to compile git stable on msys using mingw,
>>> What do you mean by "git stable"? The code from git-scm.com (or >>> git.kernel.org)? That's no more stable than Git for Windows. In fact, >>> git-scm.com redirects to the msysGit project for Windows...
>> I downloaded git source codes from git-scm.com >> Of course msysgit is more stable on Windows, but I wanted to document its >> version as stable because of rules.
> Aha, if you can somehow prove that msysGit is more stable than > upstream on Windows, then perhaps that is enough to get allowance?
>>>> but I got an error >>>> related to socklen_t. I didn't try to define it as int since socklen_t >>>> should not be depended on the endiannes of the cpu architecture. It is >>>> very >>>> difficult for me to compile git on msys since there is no bsd sockets >>>> library that can be compiled on mingw. In addition, gnulib and glibc also >>>> can't be compiled on mingw.
>>> Even upstream-git has socklen_t defined for MinGW in compat/mingw.h, >>> that should be used automatically. How exactly are you trying to build >>> Git?
>> I downloaded git-1.7.4.1, then run ./configure script on msys. I got the >> error below:
>> configure: CHECKS for typedefs, structures, and compiler characteristics >> checking for socklen_t... no >> checking for socklen_t equivalent... configure: error: Cannot find a type to >> use >> in place of socklen_t
> Aha. You don't need to run "./configure", it's only intended for > exotic Unices. Just run "make" (but be sure that you have no > config.mak.autogen left over from configure), and it should pick up > that you're building for MinGW from running uname.
>>>> I will be glad so much if "preview" word is removed since it is stable so >>>> much (the stable version even may be an old version). It is really very >>>> excellent to use git everywhere and every time.
>>> This part I tend to agree with you on. I don't think we need to say >>> that we're a preview version anymore. Git for Windows works very well >>> for me, at least. Much better than any other non-preview version >>> control system I've ever used ;)
>> I agree with you, but there are rules on our company. If the preview word is >> not removed for a long time, I will try to ask our company to accept preview >> version.
> I suspect that you'll have to go that path, but let's see if more > people agrees with us first.
> Of course, if your company would be willing to invest some development > time into Git for Windows, that'd be a very effective way of getting a > stable release ;)
Git for Windows is stock git from git-scm.com with a number of patches to ensure that it operates properly on this platform. The intent is to gradually push these patches upstream into the main project so that ultimately we just provide the necessary runtime. Expecting stock git to be more stable on Windows because it doesn't have a '-preview' suffix is ridiculous. The 50 or so patches we currently apply onto mainline git are there for a reason other than the developers idle amusement.
In my opinion it is stable. I am quite content to loose the suffix. It is that way at the moment because Johannes (and maybe other project owners) wanted to indicate quite strongly that end users are expected to fix problems and provide patches and not just issue complaints. I happen to think thats misguided. People that are inclined to make patches will do so. The others just issue so much hot air and can be ignored or not as individual contributors desire.
As I see it - if the test suite passes tolerably as has been the case for the last 4 or so releases that I've been involved with, then we may as well issue it as a 'stable' release. It passed the tests - there's not much more we can do to it to declare it more stable.
> On Mon, Mar 28, 2011 at 8:58 PM, Volkan Orhan<volkan...@gmail.com> wrote: >> On 3/28/2011 9:42 PM, Erik Faye-Lund wrote: >>> In the future, please quote in-line. This makes it much easier for >>> people to follow the discussion.
>>> On Mon, Mar 28, 2011 at 8:06 PM, Volkan Orhan<volkan...@gmail.com> wrote: >>>> I am a software engineer. I already use msysgit. I presented a git >>>> training >>>> course to my colleagues (some of them aren't software developer). In my >>>> presentation, I taught how to use tortoisegit with msysgit. I requested >>>> license for tortoisegit, but when I wanted to request license for >>>> msysgit, I >>>> saw "preview" word in its version number.
>>> Ah, you want commercial support? Unfortunately, I'm not aware of >>> anyone who provides that for Git for Windows...
>> I didn't mean commercial support for now. The license I mean is internal >> license (allowance) of our company. > Aha, thanks for clarifying.
>>>> I know that every software has bugs, so I already use beta software (even >>>> my >>>> linux is beta most of times). But our company will not want everybody to >>>> use >>>> beta or preview software.
>>>> I wanted to compile git stable on msys using mingw, >>> What do you mean by "git stable"? The code from git-scm.com (or >>> git.kernel.org)? That's no more stable than Git for Windows. In fact, >>> git-scm.com redirects to the msysGit project for Windows...
>> I downloaded git source codes from git-scm.com >> Of course msysgit is more stable on Windows, but I wanted to document its >> version as stable because of rules. > Aha, if you can somehow prove that msysGit is more stable than > upstream on Windows, then perhaps that is enough to get allowance?
I can't prove since there are strict rules in our company. I request license on license request system of our company. If I write "preview" on version section, it will probably rejected. Even if it is accepted, everybody will ask me why it is preview version. Since there are some compliance rules related to software in our company, it is some risk for me.
>>>> but I got an error >>>> related to socklen_t. I didn't try to define it as int since socklen_t >>>> should not be depended on the endiannes of the cpu architecture. It is >>>> very >>>> difficult for me to compile git on msys since there is no bsd sockets >>>> library that can be compiled on mingw. In addition, gnulib and glibc also >>>> can't be compiled on mingw.
>>> Even upstream-git has socklen_t defined for MinGW in compat/mingw.h, >>> that should be used automatically. How exactly are you trying to build >>> Git?
>> I downloaded git-1.7.4.1, then run ./configure script on msys. I got the >> error below:
>> configure: CHECKS for typedefs, structures, and compiler characteristics >> checking for socklen_t... no >> checking for socklen_t equivalent... configure: error: Cannot find a type to >> use >> in place of socklen_t
> Aha. You don't need to run "./configure", it's only intended for > exotic Unices. Just run "make" (but be sure that you have no > config.mak.autogen left over from configure), and it should pick up > that you're building for MinGW from running uname.
When I run make firstly, I get more errors like below: (I can also try 32-bit mingw if you want) CC daemon.o In file included from git-compat-util.h:149, from cache.h:4, from daemon.c:1: compat/mingw.h:8: error: conflicting types for 'pid_t' c:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-min gw32/ include/sys/types.h:67: note: previous declaration of 'pid_t' was here In file included from git-compat-util.h:149, from cache.h:4, from daemon.c:1: compat/mingw.h:137:25: error: openssl/ssl.h: No such file or directory
>>>> I will be glad so much if "preview" word is removed since it is stable so >>>> much (the stable version even may be an old version). It is really very >>>> excellent to use git everywhere and every time.
>>> This part I tend to agree with you on. I don't think we need to say >>> that we're a preview version anymore. Git for Windows works very well >>> for me, at least. Much better than any other non-preview version >>> control system I've ever used ;) >> I agree with you, but there are rules on our company. If the preview word is >> not removed for a long time, I will try to ask our company to accept preview >> version.
> I suspect that you'll have to go that path, but let's see if more > people agrees with us first.
> Of course, if your company would be willing to invest some development > time into Git for Windows, that'd be a very effective way of getting a > stable release ;)
In our team, most of the developers even don't know how to use git, so I don't think that they will help for development of git. I can help for the development of git if I can. I am a C++ developer, and mostly I develop applications using object oriented development techniques, but I don't do low level programming so much; instead, I design different layers, and I do low level programming on the lowest level. If I can help, of course I want to help development so much since I use open source software every time and everywhere.
> On 28 March 2011 20:07, Erik Faye-Lund<kusmab...@gmail.com> wrote: >> On Mon, Mar 28, 2011 at 8:58 PM, Volkan Orhan<volkan...@gmail.com> wrote: >>> On 3/28/2011 9:42 PM, Erik Faye-Lund wrote: >>>> In the future, please quote in-line. This makes it much easier for >>>> people to follow the discussion.
>>>> On Mon, Mar 28, 2011 at 8:06 PM, Volkan Orhan<volkan...@gmail.com> wrote: >>>>> I am a software engineer. I already use msysgit. I presented a git >>>>> training >>>>> course to my colleagues (some of them aren't software developer). In my >>>>> presentation, I taught how to use tortoisegit with msysgit. I requested >>>>> license for tortoisegit, but when I wanted to request license for >>>>> msysgit, I >>>>> saw "preview" word in its version number.
>>>> Ah, you want commercial support? Unfortunately, I'm not aware of >>>> anyone who provides that for Git for Windows...
>>> I didn't mean commercial support for now. The license I mean is internal >>> license (allowance) of our company. >> Aha, thanks for clarifying.
>>>>> I know that every software has bugs, so I already use beta software (even >>>>> my >>>>> linux is beta most of times). But our company will not want everybody to >>>>> use >>>>> beta or preview software.
>>>>> I wanted to compile git stable on msys using mingw, >>>> What do you mean by "git stable"? The code from git-scm.com (or >>>> git.kernel.org)? That's no more stable than Git for Windows. In fact, >>>> git-scm.com redirects to the msysGit project for Windows...
>>> I downloaded git source codes from git-scm.com >>> Of course msysgit is more stable on Windows, but I wanted to document its >>> version as stable because of rules. >> Aha, if you can somehow prove that msysGit is more stable than >> upstream on Windows, then perhaps that is enough to get allowance?
>>>>> but I got an error >>>>> related to socklen_t. I didn't try to define it as int since socklen_t >>>>> should not be depended on the endiannes of the cpu architecture. It is >>>>> very >>>>> difficult for me to compile git on msys since there is no bsd sockets >>>>> library that can be compiled on mingw. In addition, gnulib and glibc also >>>>> can't be compiled on mingw.
>>>> Even upstream-git has socklen_t defined for MinGW in compat/mingw.h, >>>> that should be used automatically. How exactly are you trying to build >>>> Git?
>>> I downloaded git-1.7.4.1, then run ./configure script on msys. I got the >>> error below:
>>> configure: CHECKS for typedefs, structures, and compiler characteristics >>> checking for socklen_t... no >>> checking for socklen_t equivalent... configure: error: Cannot find a type to >>> use >>> in place of socklen_t
>> Aha. You don't need to run "./configure", it's only intended for >> exotic Unices. Just run "make" (but be sure that you have no >> config.mak.autogen left over from configure), and it should pick up >> that you're building for MinGW from running uname.
>>>>> I will be glad so much if "preview" word is removed since it is stable so >>>>> much (the stable version even may be an old version). It is really very >>>>> excellent to use git everywhere and every time.
>>>> This part I tend to agree with you on. I don't think we need to say >>>> that we're a preview version anymore. Git for Windows works very well >>>> for me, at least. Much better than any other non-preview version >>>> control system I've ever used ;) >>> I agree with you, but there are rules on our company. If the preview word is >>> not removed for a long time, I will try to ask our company to accept preview >>> version.
>> I suspect that you'll have to go that path, but let's see if more >> people agrees with us first.
>> Of course, if your company would be willing to invest some development >> time into Git for Windows, that'd be a very effective way of getting a >> stable release ;)
> Git for Windows is stock git from git-scm.com with a number of patches > to ensure that it operates properly on this platform. The intent is to > gradually push these patches upstream into the main project so that > ultimately we just provide the necessary runtime. Expecting stock git > to be more stable on Windows because it doesn't have a '-preview' > suffix is ridiculous. The 50 or so patches we currently apply onto > mainline git are there for a reason other than the developers idle > amusement.
I don't mean that git is more stable than msysgit. I only mean that I can't ask a license for preview version. In case of a mistake of anybody, some people will say that the cause of the problem is preview version. You already know such situations.
> In my opinion it is stable. I am quite content to loose the suffix. It > is that way at the moment because Johannes (and maybe other project > owners) wanted to indicate quite strongly that end users are expected > to fix problems and provide patches and not just issue complaints. I > happen to think thats misguided. People that are inclined to make > patches will do so. The others just issue so much hot air and can be > ignored or not as individual contributors desire.
> As I see it - if the test suite passes tolerably as has been the case > for the last 4 or so releases that I've been involved with, then we > may as well issue it as a 'stable' release. It passed the tests - > there's not much more we can do to it to declare it more stable.
> Pat Thoyts.
Can't there be a stable version? It may not be updated so much, but in such cases I mentioned above, a stable version may be needed.
On Mon, Mar 28, 2011 at 9:30 PM, Volkan Orhan <volkan...@gmail.com> wrote: > On 3/28/2011 10:07 PM, Erik Faye-Lund wrote:
>> On Mon, Mar 28, 2011 at 8:58 PM, Volkan Orhan<volkan...@gmail.com> wrote:
>>> On 3/28/2011 9:42 PM, Erik Faye-Lund wrote:
>>>> In the future, please quote in-line. This makes it much easier for >>>> people to follow the discussion.
>>>> On Mon, Mar 28, 2011 at 8:06 PM, Volkan Orhan<volkan...@gmail.com> >>>> wrote:
>>>>> I am a software engineer. I already use msysgit. I presented a git >>>>> training >>>>> course to my colleagues (some of them aren't software developer). In my >>>>> presentation, I taught how to use tortoisegit with msysgit. I requested >>>>> license for tortoisegit, but when I wanted to request license for >>>>> msysgit, I >>>>> saw "preview" word in its version number.
>>>> Ah, you want commercial support? Unfortunately, I'm not aware of >>>> anyone who provides that for Git for Windows...
>>> I didn't mean commercial support for now. The license I mean is internal >>> license (allowance) of our company.
>> Aha, thanks for clarifying.
>>>>> I know that every software has bugs, so I already use beta software >>>>> (even >>>>> my >>>>> linux is beta most of times). But our company will not want everybody >>>>> to >>>>> use >>>>> beta or preview software.
>>>>> I wanted to compile git stable on msys using mingw,
>>>> What do you mean by "git stable"? The code from git-scm.com (or >>>> git.kernel.org)? That's no more stable than Git for Windows. In fact, >>>> git-scm.com redirects to the msysGit project for Windows...
>>> I downloaded git source codes from git-scm.com >>> Of course msysgit is more stable on Windows, but I wanted to document its >>> version as stable because of rules.
>> Aha, if you can somehow prove that msysGit is more stable than >> upstream on Windows, then perhaps that is enough to get allowance?
> I can't prove since there are strict rules in our company. I request license > on license request system of our company. If I write "preview" on version > section, it will probably rejected. Even if it is accepted, everybody will > ask me why it is preview version. Since there are some compliance rules > related to software in our company, it is some risk for me.
>>>>> but I got an error >>>>> related to socklen_t. I didn't try to define it as int since socklen_t >>>>> should not be depended on the endiannes of the cpu architecture. It is >>>>> very >>>>> difficult for me to compile git on msys since there is no bsd sockets >>>>> library that can be compiled on mingw. In addition, gnulib and glibc >>>>> also >>>>> can't be compiled on mingw.
>>>> Even upstream-git has socklen_t defined for MinGW in compat/mingw.h, >>>> that should be used automatically. How exactly are you trying to build >>>> Git?
>>> I downloaded git-1.7.4.1, then run ./configure script on msys. I got the >>> error below:
>>> configure: CHECKS for typedefs, structures, and compiler characteristics >>> checking for socklen_t... no >>> checking for socklen_t equivalent... configure: error: Cannot find a type >>> to >>> use >>> in place of socklen_t
>> Aha. You don't need to run "./configure", it's only intended for >> exotic Unices. Just run "make" (but be sure that you have no >> config.mak.autogen left over from configure), and it should pick up >> that you're building for MinGW from running uname.
> When I run make firstly, I get more errors like below: (I can also try > 32-bit mingw if you want) > CC daemon.o > In file included from git-compat-util.h:149, > from cache.h:4, > from daemon.c:1: > compat/mingw.h:8: error: conflicting types for 'pid_t' > c:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-min gw32/ > include/sys/types.h:67: note: previous declaration of 'pid_t' was here
This is probably because you're using a different version of MinGW than we are. Strangely enough, our /mingw/include/sys/types.h does have a definition for pid_t:
$ grep -C3 pid_t /mingw/include/sys/types.h
#ifndef _PID_T_ #define _PID_T_ typedef int _pid_t;
I'm not entirely sure why this doesn't get picked up when we compile. You can probably just remove the definition locally.
> In file included from git-compat-util.h:149, > from cache.h:4, > from daemon.c:1: > compat/mingw.h:137:25: error: openssl/ssl.h: No such file or directory
This is because Git depends on OpenSSL, so you either have to compile and install it or add a line saying "NO_OPENSSL = YesPlease" to your config.mak (create it if it doesn't exist) to build a stripped-down version that doesn't use the features that require OpenSSL.
> On Mon, Mar 28, 2011 at 9:30 PM, Volkan Orhan<volkan...@gmail.com> wrote: >> On 3/28/2011 10:07 PM, Erik Faye-Lund wrote: >>> On Mon, Mar 28, 2011 at 8:58 PM, Volkan Orhan<volkan...@gmail.com> wrote: >>>> On 3/28/2011 9:42 PM, Erik Faye-Lund wrote: >>>>> In the future, please quote in-line. This makes it much easier for >>>>> people to follow the discussion.
>>>>> On Mon, Mar 28, 2011 at 8:06 PM, Volkan Orhan<volkan...@gmail.com> >>>>> wrote: >>>>>> I am a software engineer. I already use msysgit. I presented a git >>>>>> training >>>>>> course to my colleagues (some of them aren't software developer). In my >>>>>> presentation, I taught how to use tortoisegit with msysgit. I requested >>>>>> license for tortoisegit, but when I wanted to request license for >>>>>> msysgit, I >>>>>> saw "preview" word in its version number.
>>>>> Ah, you want commercial support? Unfortunately, I'm not aware of >>>>> anyone who provides that for Git for Windows...
>>>> I didn't mean commercial support for now. The license I mean is internal >>>> license (allowance) of our company. >>> Aha, thanks for clarifying.
>>>>>> I know that every software has bugs, so I already use beta software >>>>>> (even >>>>>> my >>>>>> linux is beta most of times). But our company will not want everybody >>>>>> to >>>>>> use >>>>>> beta or preview software.
>>>>>> I wanted to compile git stable on msys using mingw, >>>>> What do you mean by "git stable"? The code from git-scm.com (or >>>>> git.kernel.org)? That's no more stable than Git for Windows. In fact, >>>>> git-scm.com redirects to the msysGit project for Windows...
>>>> I downloaded git source codes from git-scm.com >>>> Of course msysgit is more stable on Windows, but I wanted to document its >>>> version as stable because of rules. >>> Aha, if you can somehow prove that msysGit is more stable than >>> upstream on Windows, then perhaps that is enough to get allowance?
>> I can't prove since there are strict rules in our company. I request license >> on license request system of our company. If I write "preview" on version >> section, it will probably rejected. Even if it is accepted, everybody will >> ask me why it is preview version. Since there are some compliance rules >> related to software in our company, it is some risk for me. >>>>>> but I got an error >>>>>> related to socklen_t. I didn't try to define it as int since socklen_t >>>>>> should not be depended on the endiannes of the cpu architecture. It is >>>>>> very >>>>>> difficult for me to compile git on msys since there is no bsd sockets >>>>>> library that can be compiled on mingw. In addition, gnulib and glibc >>>>>> also >>>>>> can't be compiled on mingw.
>>>>> Even upstream-git has socklen_t defined for MinGW in compat/mingw.h, >>>>> that should be used automatically. How exactly are you trying to build >>>>> Git?
>>>> I downloaded git-1.7.4.1, then run ./configure script on msys. I got the >>>> error below:
>>>> configure: CHECKS for typedefs, structures, and compiler characteristics >>>> checking for socklen_t... no >>>> checking for socklen_t equivalent... configure: error: Cannot find a type >>>> to >>>> use >>>> in place of socklen_t
>>> Aha. You don't need to run "./configure", it's only intended for >>> exotic Unices. Just run "make" (but be sure that you have no >>> config.mak.autogen left over from configure), and it should pick up >>> that you're building for MinGW from running uname.
>> When I run make firstly, I get more errors like below: (I can also try >> 32-bit mingw if you want) >> CC daemon.o >> In file included from git-compat-util.h:149, >> from cache.h:4, >> from daemon.c:1: >> compat/mingw.h:8: error: conflicting types for 'pid_t' >> c:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-min gw32/ >> include/sys/types.h:67: note: previous declaration of 'pid_t' was here > This is probably because you're using a different version of MinGW > than we are. Strangely enough, our /mingw/include/sys/types.h does > have a definition for pid_t:
> $ grep -C3 pid_t /mingw/include/sys/types.h
> #ifndef _PID_T_ > #define _PID_T_ > typedef int _pid_t;
> I'm not entirely sure why this doesn't get picked up when we compile. > You can probably just remove the definition locally.
I don't have that file. I will install 32-bit mingw tomorrow.
>> In file included from git-compat-util.h:149, >> from cache.h:4, >> from daemon.c:1: >> compat/mingw.h:137:25: error: openssl/ssl.h: No such file or directory
> This is because Git depends on OpenSSL, so you either have to compile > and install it or add a line saying "NO_OPENSSL = YesPlease" to your > config.mak (create it if it doesn't exist) to build a stripped-down > version that doesn't use the features that require OpenSSL.
I will also add or compile openssl library. Thank you very much for the solution. The best solution would be to have msysgit without "preview" word. But since we don't have it for now, and we have strict rules, I should compile git to get a allowance from our company.
On Mon, Mar 28, 2011 at 9:55 PM, Erik Faye-Lund <kusmab...@gmail.com> wrote: > On Mon, Mar 28, 2011 at 9:30 PM, Volkan Orhan <volkan...@gmail.com> wrote: >> When I run make firstly, I get more errors like below: (I can also try >> 32-bit mingw if you want) >> CC daemon.o >> In file included from git-compat-util.h:149, >> from cache.h:4, >> from daemon.c:1: >> compat/mingw.h:8: error: conflicting types for 'pid_t' >> c:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-min gw32/ >> include/sys/types.h:67: note: previous declaration of 'pid_t' was here
> This is probably because you're using a different version of MinGW > than we are. Strangely enough, our /mingw/include/sys/types.h does > have a definition for pid_t:
> $ grep -C3 pid_t /mingw/include/sys/types.h
> #ifndef _PID_T_ > #define _PID_T_ > typedef int _pid_t;
> I'm not entirely sure why this doesn't get picked up when we compile. > You can probably just remove the definition locally.
Actually it's picked up, but it's just a compatible definition here (both define it to "int").
Simply removing the definition should be the trick. J6t, you added the definition back in ancient times: Am I right in suspecting that older MinGWs didn't supply pid_t, or do you think it might have simply been a left-over from something?
It'd be nice if we could start preparing a bit more for MinGW-64 support, and I'm a little bit unsure how to do this - remove the definition all together or guard it with a _PID_T_-check... The latter would be the careful choice, I guess.
> On Mon, Mar 28, 2011 at 9:55 PM, Erik Faye-Lund<kusmab...@gmail.com> wrote: >> On Mon, Mar 28, 2011 at 9:30 PM, Volkan Orhan<volkan...@gmail.com> wrote: >>> When I run make firstly, I get more errors like below: (I can also try >>> 32-bit mingw if you want) >>> CC daemon.o >>> In file included from git-compat-util.h:149, >>> from cache.h:4, >>> from daemon.c:1: >>> compat/mingw.h:8: error: conflicting types for 'pid_t' >>> c:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-min gw32/ >>> include/sys/types.h:67: note: previous declaration of 'pid_t' was here >> This is probably because you're using a different version of MinGW >> than we are. Strangely enough, our /mingw/include/sys/types.h does >> have a definition for pid_t:
>> $ grep -C3 pid_t /mingw/include/sys/types.h
>> #ifndef _PID_T_ >> #define _PID_T_ >> typedef int _pid_t;
>> I'm not entirely sure why this doesn't get picked up when we compile. >> You can probably just remove the definition locally.
> Actually it's picked up, but it's just a compatible definition here > (both define it to "int").
> Simply removing the definition should be the trick. J6t, you added the > definition back in ancient times: Am I right in suspecting that older > MinGWs didn't supply pid_t, or do you think it might have simply been > a left-over from something?
> It'd be nice if we could start preparing a bit more for MinGW-64 > support, and I'm a little bit unsure how to do this - remove the > definition all together or guard it with a _PID_T_-check... The latter > would be the careful choice, I guess.
Definition of socklen_t as int may not be a good solution since big endian and small endian systems write int differently. This may not be problem for Windows, but git is multiplatform. I don't know how this type is used in git codes, but I think that this may cause some problems in the future.
On Mon, Mar 28, 2011 at 10:22 PM, Volkan Orhan <volkan...@gmail.com> wrote: > On 3/28/2011 11:13 PM, Erik Faye-Lund wrote:
>> On Mon, Mar 28, 2011 at 9:55 PM, Erik Faye-Lund<kusmab...@gmail.com> >> wrote:
>>> On Mon, Mar 28, 2011 at 9:30 PM, Volkan Orhan<volkan...@gmail.com> >>> wrote:
>>>> When I run make firstly, I get more errors like below: (I can also try >>>> 32-bit mingw if you want) >>>> CC daemon.o >>>> In file included from git-compat-util.h:149, >>>> from cache.h:4, >>>> from daemon.c:1: >>>> compat/mingw.h:8: error: conflicting types for 'pid_t'
>>>> c:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-min gw32/ >>>> include/sys/types.h:67: note: previous declaration of 'pid_t' was here
>>> This is probably because you're using a different version of MinGW >>> than we are. Strangely enough, our /mingw/include/sys/types.h does >>> have a definition for pid_t:
>>> $ grep -C3 pid_t /mingw/include/sys/types.h
>>> #ifndef _PID_T_ >>> #define _PID_T_ >>> typedef int _pid_t;
>>> I'm not entirely sure why this doesn't get picked up when we compile. >>> You can probably just remove the definition locally.
>> Actually it's picked up, but it's just a compatible definition here >> (both define it to "int").
>> Simply removing the definition should be the trick. J6t, you added the >> definition back in ancient times: Am I right in suspecting that older >> MinGWs didn't supply pid_t, or do you think it might have simply been >> a left-over from something?
>> It'd be nice if we could start preparing a bit more for MinGW-64 >> support, and I'm a little bit unsure how to do this - remove the >> definition all together or guard it with a _PID_T_-check... The latter >> would be the careful choice, I guess.
> Definition of socklen_t as int may not be a good solution since big endian > and small endian systems write int differently. This may not be problem for > Windows, but git is multiplatform. I don't know how this type is used in git > codes, but I think that this may cause some problems in the future.
This definition is in compat/mingw.h, so it doesn't matter how multi-platform git is, it will only be included when compiling on Windows.
And even we did use this on a big-endian machine, it would still have been correct (provided that the platform didn't provide a conflicting definition). It's the in-memory representation that is different for big-endian machines - an int is an int no matter what :)
> On Mon, Mar 28, 2011 at 9:55 PM, Erik Faye-Lund <kusmab...@gmail.com> wrote: > > On Mon, Mar 28, 2011 at 9:30 PM, Volkan Orhan <volkan...@gmail.com> wrote: > >> When I run make firstly, I get more errors like below: (I can also try > >> 32-bit mingw if you want) > >> CC daemon.o > >> In file included from git-compat-util.h:149, > >> from cache.h:4, > >> from daemon.c:1: > >> compat/mingw.h:8: error: conflicting types for 'pid_t' > >> c:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64- > >>mingw32/ include/sys/types.h:67: note: previous declaration of 'pid_t' > >> was here
> > This is probably because you're using a different version of MinGW > > than we are. Strangely enough, our /mingw/include/sys/types.h does > > have a definition for pid_t:
> > I'm not entirely sure why this doesn't get picked up when we compile. > > You can probably just remove the definition locally.
> Actually it's picked up, but it's just a compatible definition here > (both define it to "int").
> Simply removing the definition should be the trick. J6t, you added the > definition back in ancient times: Am I right in suspecting that older > MinGWs didn't supply pid_t, or do you think it might have simply been > a left-over from something?
I don't remember for sure, but I think that older MinGW did not define pid_t.
On Mon, Mar 28, 2011 at 11:07:13PM +0300, Volkan Orhan wrote: > I will also add or compile openssl library. Thank you very much for the > solution. > The best solution would be to have msysgit without "preview" word. But > since we don't have it for now, and we have strict rules, I should > compile git to get a allowance from our company.
Why are you doing it the hard way? Just install the development environment (msysgit installer).
1. Checkout the version you want to test whether its stable enough for you.
2. Start msys.bat and make install
3. Verify whether its stable enough for you: i.e. run the testsuite using /share/msysGit/run-tests.sh (Tip: disable any virus protection because the slowlyness interferes with the test scripts)
4. Hack on things you do want/need to have fixed and send the patches to this list.
5. Build your own installer: /share/WinGit/release.sh <versionnumber>
Now you should have your very own "stable" version.
Cheers Heiko
P.S.: Wasn't there a roadmap from Johannes somewhere which described what would need to be done for the first stable release? I think "all tests pass" was one item on there and thats what I would expect for a publicly stable release.
On Mon, 28 Mar 2011, Erik Faye-Lund wrote: > On Mon, Mar 28, 2011 at 5:53 PM, Johannes Schindelin > <Johannes.Schinde...@gmx.de> wrote: > > Hi,
> > On Mon, 28 Mar 2011, csh wrote:
> >> I want to use msysgit with tortoisegit in the company that I work > >> for, but I can't get an approval for msysgit since its version is > >> preview. What time can its stable version be released?
> > Git for Windows is free software. You have two options:
> > 1) work on it yourself until it fulfills your quality criteria, or
> > 2) pay somebody to get it there.
> > Specifically, if your goal is to remove the "-preview" from the > > package name, you can
> > 1) rename the file, or
> > 2) state more clearly what your company deems stable enough, and hope > > that �somebody gives you an estimate how much it would cost to get > > it there.
> While I agree with what you're saying here, perhaps we should consider > losing the "-preview"-suffix anyway?
I am strictly against that. Not only does it encourage companies' managers to think about Git lowly (because it does not cost anything -- and I speak very much from experience here), but it also would provide no respect for the few faithful Git for Windows developers, such as you, Pat, Heiko & Jens and the two Kirills (and a few others...).
Face it: companies can easily afford a couple of thousand Euros to get the support they require. The rule of thumb is: 1000 EUR per freelancer per day. A couple of thousand Euros here and there is not only reasonable to ask for, it also does not hurt companies in the least.
IMO it is quite obvious that putting an effort to get Git for Windows to -stable status for no money at all would be a lose-lose situation for all parties involved: those developers who could maintain the -stable status for a decent amount of time (read: more than a couple of days) would still have to earn their living with different jobs, doing Git for Windows in their precious free time. And companies who have a false impression of saving money would lose out on high-quality maintenance, resulting in a non-stable Git in the long run.
I do want to encourage Git for Windows contributors to think about their incentives of working on Git. If it is for your own end, fine. If you publish your changes, even better.
But if you work for somebody else's end, especially on Windows, which is a thoroughly commercial system, you should consider asking yourself what's in it for you, in the long run. To be able to sustain your contributions.
After all, a high degree of intelligence and experience and persistence is required to work on high-quality software. Which comes at a price.
> I mean, Git for Windows is the de facto Git distribution for Windows, > and I think it's closing in on getting "stable enough" (a very > subjective measure, I know). Quite a bit of people seem to be confused > by the naming already.
That is a different issue altogether.
> After all, removing the "-preview"-suffix won't make Git for Windows > unfree software. People will still have to pay or convince someone to do > work for them (unless they're willing to do it themselves), like with > most other free software...
It's not about making Git "free" or "unfree". Git -- and therefore also Git on Windows -- _is_ free software. Free as in freedom. But that does not mean that the developers pushing Git for Windows should try their best to spend all their non-day job time to solve other people's problems for a warm handshake instead of spending their time with their family and friends. Because it _will_ wear them out.
> If we decide to do this, I'd suggest doing it at the same time as > changing the naming for our packages as has been suggested before (if we > even end up deciding to do that as well, of course). I'd like to see > something like this:
That is a good naming we could easily have with a -preview suffix until the time that one or more companies compensate the top contributors of Git for Windows for their efforts.
After all, the top two _Git_ developers were hired by Google, and are now paid top dollar.
> I'm not so sure about the netinstall; why do we have new releases of the > netinstall with every release? Isn't it just cloning the > always-up-to-date repo on repo.or.cz? As long as we have tags for every > released versions, can't we just maintain one binary? Or is there > something I'm missing?
The reasoning was two-fold:
1) we had quite a few problems with older -netinstall not being able to cope with newer developments, for example when we made 'devel' the primary development branch (and it took an incredible amount of time and patience and download quota to test and fix those things), and
2) Google (in the person of Shawn Pearce, #2 of the _Git_ developers) said that we had a lot of quota and would get more when we need it, so there was little point in saving on space with the net installers.
Just to clarify on my previous argument: there has been a _lot_ of time invested in Git for Windows. Last time I calculated, I myself put in easily a thousand hours of work just for the Windows port of Git. It is only fair to expect something more than requests (to stabilize, to fix, to support X, Y and Z) back. Be that code contributions, be that money.
You mentioned yourself a couple of times that it is dirt-easy to build Git, and it is dirt-easy to build a Git installer.
These are not things that just happen, or for that matter, that are provided in just a couple of free afternoon's time. These things cost _real_ time. We're talking about weeks and months of dedicated work.
Git-svn alone (which still would offer the opportunity for at least 500 more hours to get to work properly) cost me several months of almost every bit of my free, unpaid time, personally. Maybe I should not have been as modest as I was when I wrote about this in the MsysGit Heralds.
In the upstream Git project, there seems to be no problem to find contributors who make an immense initial effort worthwhile because you get more back than you spent. For some reason, the same is not true in Git for Windows (I can count the contributors with one hand, using the binary system).
So, much as I respect Pat for what he did both with Tcl/Tk and Git for Windows, I _do_ think that it would be a wise thing to put in all the work to get Git for Windows into a shape competing with non-Windows versions of Git, but _only_ if due respect is paid either by contributions or in financial form.
Everything else would just elicit fully deserved ridicule by anybody versed in the world of management and/or trading.
Ciao, Dscho
P.S.: When I happened to stumble upon a project manager of a company back last August who migrated his team to Git (for Windows) but had a number of complaints about stability, my suggestion to hire somebody to fix things was met with very wide eyes. He took Git for something God-given. But then, he also did not realize that he was talking to the Git for Windows maintainer. I fully believe that I deserve more respect (which equals money in the corporate world) than that.
On Mon, 28 Mar 2011, Erik Faye-Lund wrote: > It'd be nice if we could start preparing a bit more for MinGW-64 > support, and I'm a little bit unsure how to do this - remove the > definition all together or guard it with a _PID_T_-check... The latter > would be the careful choice, I guess.
Have you actually seen the work/w64 branch of 4msysgit.git? This is something I started to work on a couple of months back, and am now picking up again, as a company realized that you get kick-ass support if you pay decent money for it.
On Mon, 28 Mar 2011, Volkan Orhan wrote: > The company I work for has very strict rules.
I understand that, as I am quite familiar with the corporate environment.
However, as you will certainly understand, such substantial demands can only be met for an appropriate price.
> Normally I already use beta software personally. Of course my goal is > not to remove "-preview", but our software committee will review > everything, and because of the "preview" word on the version number, it > may be rejected.
> Isn't it possible for msysgit to be released as stable version?
There is. But what your software committee needs is not a rename. Your committee needs to have a guarantee. A guarantee which can only possibly be met through a detailed audit. Which requires a service contract that puts a large burden on the contractor guaranteeing stability.
I am sure that you understand that a fair contract to such an end would need to be met with an appropriate financial investment, as only those people would guarantee such a degree of stability for free (with liability) who lack the intellectual capabilities to actually ensure that degree of stability.
On Mon, 28 Mar 2011, Volkan Orhan wrote: > If I was a project manager, of course I would support both git and > msysgit. I can't say that "we should take support for msysgit to have > stable version of msysgit" because of my position. For now, I am only > able compile git on mingw.
> I really want to support both git and msysgit, but I am not able to > support both of them financially for now. I can spend my free times as I > said before for both git and msysgit.
If I was a project manager, of course I would support both git and
msysgit. I can't say that "we should take support for msysgit to have
stable version of msysgit" because of my position. For now, I am only
able compile git on mingw.
I really want to support both git and msysgit, but I am not able to
support both of them financially for now. I can spend my free times as
I said before for both git and msysgit.
By the way, thank you all for your help.
Best regards,
Volkan Orhan
On Mar 29, 3:42 am, Johannes Schindelin <Johannes.Schinde...@gmx.de>
wrote:
> On Mon, 28 Mar 2011, Erik Faye-Lund wrote:
> > On Mon, Mar 28, 2011 at 5:53 PM, Johannes Schindelin
> > <Johannes.Schinde...@gmx.de> wrote:
> > > Hi,
> > > On Mon, 28 Mar 2011, csh wrote:
> > >> I want to use msysgit with tortoisegit in the company that I work
> > >> for, but I can't get an approval for msysgit since its version is
> > >> preview. What time can its stable version be released?
> > > Git for Windows is free software. You have two options:
> > > 1) work on it yourself until it fulfills your quality criteria, or
> > > 2) pay somebody to get it there.
> > > Specifically, if your goal is to remove the "-preview" from the
> > > package name, you can
> > > 1) rename the file, or
> > > 2) state more clearly what your company deems stable enough, and hope
> > > that �somebody gives you an estimate how much it would cost to get
> > > it there.
> > While I agree with what you're saying here, perhaps we should consider
> > losing the "-preview"-suffix anyway?
> I am strictly against that. Not only does it encourage companies' managers
> to think about Git lowly (because it does not cost anything -- and I speak
> very much from experience here), but it also would provide no respect for
> the few faithful Git for Windows developers, such as you, Pat, Heiko &
> Jens and the two Kirills (and a few others...).
> Face it: companies can easily afford a couple of thousand Euros to get the
> support they require. The rule of thumb is: 1000 EUR per freelancer per
> day. A couple of thousand Euros here and there is not only reasonable to
> ask for, it also does not hurt companies in the least.
> IMO it is quite obvious that putting an effort to get Git for Windows to
> -stable status for no money at all would be a lose-lose situation for all
> parties involved: those developers who could maintain the -stable status
> for a decent amount of time (read: more than a couple of days) would still
> have to earn their living with different jobs, doing Git for Windows in
> their precious free time. And companies who have a false impression of
> saving money would lose out on high-quality maintenance, resulting in a
> non-stable Git in the long run.
> I do want to encourage Git for Windows contributors to think about their
> incentives of working on Git. If it is for your own end, fine. If you
> publish your changes, even better.
> But if you work for somebody else's end, especially on Windows, which is a
> thoroughly commercial system, you should consider asking yourself
> what's in it for you, in the long run. To be able to sustain your
> contributions.
> After all, a high degree of intelligence and experience and persistence is
> required to work on high-quality software. Which comes at a price.
> > I mean, Git for Windows is the de facto Git distribution for Windows,
> > and I think it's closing in on getting "stable enough" (a very
> > subjective measure, I know). Quite a bit of people seem to be confused
> > by the naming already.
> That is a different issue altogether.
> > After all, removing the "-preview"-suffix won't make Git for Windows
> > unfree software. People will still have to pay or convince someone to do
> > work for them (unless they're willing to do it themselves), like with
> > most other free software...
> It's not about making Git "free" or "unfree". Git -- and therefore also
> Git on Windows -- _is_ free software. Free as in freedom. But that does
> not mean that the developers pushing Git for Windows should try their best
> to spend all their non-day job time to solve other people's problems for a
> warm handshake instead of spending their time with their family and
> friends. Because it _will_ wear them out.
> > If we decide to do this, I'd suggest doing it at the same time as
> > changing the naming for our packages as has been suggested before (if we
> > even end up deciding to do that as well, of course). I'd like to see
> > something like this:
> That is a good naming we could easily have with a -preview suffix until
> the time that one or more companies compensate the top contributors of Git
> for Windows for their efforts.
> After all, the top two _Git_ developers were hired by Google, and are now
> paid top dollar.
> > I'm not so sure about the netinstall; why do we have new releases of the
> > netinstall with every release? Isn't it just cloning the
> > always-up-to-date repo on repo.or.cz? As long as we have tags for every
> > released versions, can't we just maintain one binary? Or is there
> > something I'm missing?
> The reasoning was two-fold:
> 1) we had quite a few problems with older -netinstall not being able to
> cope with newer developments, for example when we made 'devel' the
> primary development branch (and it took an incredible amount of time
> and patience and download quota to test and fix those things), and
> 2) Google (in the person of Shawn Pearce, #2 of the _Git_ developers) said
> that we had a lot of quota and would get more when we need it, so there
> was little point in saving on space with the net installers.
> Just to clarify on my previous argument: there has been a _lot_ of time
> invested in Git for Windows. Last time I calculated, I myself put in
> easily a thousand hours of work just for the Windows port of Git. It is
> only fair to expect something more than requests (to stabilize, to fix, to
> support X, Y and Z) back. Be that code contributions, be that money.
> You mentioned yourself a couple of times that it is dirt-easy to build
> Git, and it is dirt-easy to build a Git installer.
> These are not things that just happen, or for that matter, that are
> provided in just a couple of free afternoon's time. These things cost
> _real_ time. We're talking about weeks and months of dedicated work.
> Git-svn alone (which still would offer the opportunity for at least 500
> more hours to get to work properly) cost me several months of almost every
> bit of my free, unpaid time, personally. Maybe I should not have been as
> modest as I was when I wrote about this in the MsysGit Heralds.
> In the upstream Git project, there seems to be no problem to find
> contributors who make an immense initial effort worthwhile because you get
> more back than you spent. For some reason, the same is not true in Git for
> Windows (I can count the contributors with one hand, using the binary
> system).
> So, much as I respect Pat for what he did both with Tcl/Tk and Git for
> Windows, I _do_ think that it would be a wise thing to put in all the
> work to get Git for Windows into a shape competing with non-Windows
> versions of Git, but _only_ if due respect is paid either by contributions
> or in financial form.
> Everything else would just elicit fully deserved ridicule by anybody
> versed in the world of management and/or trading.
> Ciao,
> Dscho
> P.S.: When I happened to stumble upon a project manager of a company back
> last August who migrated his team to Git (for Windows) but had a number of
> complaints about stability, my suggestion to hire somebody to fix things
> was met with very wide eyes. He took Git for something God-given. But
> then, he also did not realize that he was talking to the Git for Windows
> maintainer. I fully believe that I deserve more respect (which equals
> money in the corporate world) than that.
> On 3/28/2011 11:13 PM, Erik Faye-Lund wrote: >> On Mon, Mar 28, 2011 at 9:55 PM, Erik Faye-Lund<kusmab...@gmail.com> >> wrote: >>> On Mon, Mar 28, 2011 at 9:30 PM, Volkan Orhan<volkan...@gmail.com> >>> wrote: >>>> When I run make firstly, I get more errors like below: (I can also try >>>> 32-bit mingw if you want) >>>> CC daemon.o >>>> In file included from git-compat-util.h:149, >>>> from cache.h:4, >>>> from daemon.c:1: >>>> compat/mingw.h:8: error: conflicting types for 'pid_t' >>>> c:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-min gw32/
>>>> include/sys/types.h:67: note: previous declaration of 'pid_t' was here >>> This is probably because you're using a different version of MinGW >>> than we are. Strangely enough, our /mingw/include/sys/types.h does >>> have a definition for pid_t:
>>> $ grep -C3 pid_t /mingw/include/sys/types.h
>>> #ifndef _PID_T_ >>> #define _PID_T_ >>> typedef int _pid_t;
>>> I'm not entirely sure why this doesn't get picked up when we compile. >>> You can probably just remove the definition locally.
>> Actually it's picked up, but it's just a compatible definition here >> (both define it to "int").
>> Simply removing the definition should be the trick. J6t, you added the >> definition back in ancient times: Am I right in suspecting that older >> MinGWs didn't supply pid_t, or do you think it might have simply been >> a left-over from something?
>> It'd be nice if we could start preparing a bit more for MinGW-64 >> support, and I'm a little bit unsure how to do this - remove the >> definition all together or guard it with a _PID_T_-check... The latter >> would be the careful choice, I guess. > Definition of socklen_t as int may not be a good solution since big > endian and small endian systems write int differently. This may not be > problem for Windows, but git is multiplatform. I don't know how this > type is used in git codes, but I think that this may cause some problems > in the future.
socklen_t is used between the user application (your C program, git in our case) and the socket layer. It tells about the length of the address, not about the address itself. The length we look at here has nothing to do with data exchanged on the network. (Well it has, since e.g. IPV4 and IPV6 addresses have different length). But the length information in socklen_t is always in "machine endianes" as all other ints in the world are. /Torsten
