On Aug 10, 2007, at 12:30 PM, Johannes Schindelin wrote:
Hi,
On Fri, 10 Aug 2007, Steffen Prohaska wrote:
On Aug 10, 2007, at 8:07 AM, Torgil Svensson wrote:
On 8/9/07, Steffen Prohaska <prohaska@xxxxxx> wrote:
Will all this run on Windows XP 64 bit and Windows Vista 64 bit?
How fast can you type?
I don't see your point. The question is if git runs flawlessly
on 64 bit systems, which we use for development. I have no experience
with mingw. Maybe there are some issues with 64 bit Windows, maybe
not. But its a reasonable question?
It would be, if
- more people had 64-bit platforms to run on, and
- more people had Windows 64-bit.
Both cost money, so I suggest just trying it for yourself if you
are one
of the few lucky ones being actually _able_ to test.
And no, I will not buy a Windows 64-bit just to test it for you.
I'll try. I only asked if there is any experience on this. I didn't
ask you to test it for me.
Why does it have to be the _official_ repo? Git have submodule
support, so you could do a repo called
"my_excellent_git_environment_for_windows.git" and have the official
repo as submodule (msysgit is done this way).
The official repo would indicate a real commitment to me that
Windows support if officially maintained.
I cannot speak for others, of course, but this is a freeloader
mentality I
do not want to support.
If you want first class Windows support, you'll have to pay for that,
methinks. And seeing all those less-than-even-lousy SCMs getting
major
financial contributions to support their mediocrity, I do not see a
reason
to get small amounts from private people, but rather substantial
money-flow from big companies.
Git is an excellent tool. If people want it badly enough, they
should do
something for it.
You may have noticed that I'm willing to put some time into
it. I can't offer money. Time should be fine, too as you
state on msysgit's homepage
"Testing and reporting bugs is really already a big help.
Of course, it is even better if you get involved, for example
by hacking on mingw.git."
That is what I'm doing. You get bug reports and you get
patches. I don't understand your point about freeloader
mentality. In the long run it's just easier to keep functionality
in sync if it is maintained in a single repo, and this is what
you're basically also saying below.
I agree that there may be more tools group around core git. But
core git itself should be the master from the official repo.
This seems to be a reasonable goal to me. At least that is what
we do. The head must compile on all supported platforms
out-of-the-box.
Guess why mingw.git is called a "fork"? It is _not good enough_
yet to be
included. Not necessarily function-wise, but definitely code-
wise. We
have quite strict coding rules, being an Open Source project where
everybody can see your mess, should there be one.
Well and here, again, is my point of one single repo that officially
supports Windows. If the official support is part of the 'quite
strict coding' rules then I'm more convinced that Windows is
supported with appropriate quality. This is the point I want to make.
It has nothing to do with freeloader mentality.
It has _never_ been the plan to maintain mingw.git independently for
eternity. But the progress has been slow, and the _only_ reason that
there was any progress _at all_ was that Hannes stepped up, and did
some
actual work instead of talking.
So yes, mingw.git's target destination is git.git.
Good to hear. Again, I prefer to put work into pushing the merge
with git.git forward, than putting work into any fancy gui stuff,
as you proposed recently.
So if there's a list of todos that hinder a merge back to git.git,
I'd happy to learn about it.
Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
