On Aug 11, 2007, at 12:31 AM, Torgil Svensson wrote:

quoted text
> On 8/10/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
>>  [..list of tools and links]
>
> Thank you for the information!  i'll check those up.


I hope to have an improved list on monday, sorted by priority of
the developers I'm working with.

I thought I do some coding, to find out a bit more about the
stability of msysgit. So I started and added support for kdiff3
on Windows (see patches in separate mail).

I'm impressed. Pretty much everything I tried today worked for
me. After I got git gui running, and learned how to avoid pitfalls
of git submodule, development went smoothly. I pushed and pulled a
bit from linux and mac and did some coding. Thanks for the vim
setup!

I think you (and more people I don't yet know) did a great job
with msysgit. I'd recommend it over cygwin's git, which caused
some trouble for me.

Thanks!

quoted text
>>>> My goal would be to type 'make windist' in the official repo and
>>>> get a very basic installer (maybe just a zip archive) that contains
>>>> everything needed to run git on Windows. Unpacking this self-
>>>> contained
>>>> installer on a freshly installed Windows should get you going.  
>>>> There
>>>> should be no need to install Cygwin or something else.
>>>>
>>>> Is this realistic?
>>>> What is needed to get there?
>>>> What would be an estimated timeframe to achieve this goal?
>>>>
>>>> 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?
>>
>>> 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 agree it's reasonable questions. My point is that to get something,
> you have to be active (and you're a prime example of that I think).
>
> Quoted from http://git.or.cz/ : "Traditionally, the low-level part of
> Git is called plumbing and the interfaces and frontends are called
> porcelains. Git itself comes with a default porcelain bundled and that
> is actually what you will normally mean when you say you use Git."
>
>
> What do you include in the "make windist" installer and the "Windows
> support" ?  Are you talking porcelain or plumbing?

Hard to say. I believe now, from what I learned today, that the msysgit
approach is quite reasonable: Grouping all needed unix tools around a
submodule containing git. But the submodule should be git.git. I think
this is what I'd expect. I like the idea of bringing everything needed
along, and keeping it separate from the rest of the system. This avoids
conflicts with, for example, cygwin.

I don't think I would expect much more for a basic setup. All tests
should run, maybe some msysgit tests would be needed to test the  
pitfalls
we'll discover; maybe not. I'll test XP 64 bit and Vista 64 bit  
beginning
of next week. Getting started hacking msysgit could be a bit easier.
I didn't like the submodule problems I ran into and I still didn't find
out how to push to the git mob branch.

For me a next step would be do some polishing. For example tune
git to integrate with other Windows tools, like what I proposed for
git-mergetool. I really started to love git when it launched a
graphical mergetool automatically for me. After that point I never
edited merge markers again. Things I needed too much time before are
now running so smoothly. I think such a tight integration is really
useful to convince people. I'd also expect default choices to be
reasonable. I'm not yet 100% sure, but my feeling it that core.autocrlf
should be set to true by default on Windows, globally. A bit more
of msysgit specific documentation would also be good. Maybe we should
add a platform specific section to the user-manual. How could help
in msysgit be handled? By a Windows help document?

I could also think of a fail safe update, that allows to upgrade an
existing msysgit to a specific tag (maybe after stashing the current
installation and reverting in case of problems).

Maybe git gui could be integrated with the Windows Explorer and be
launched on a directory. Maybe this is one of your evil plans. But
this is already more than I need.

Back to the basic stuff.
What do you think is needed to merge changes back to git.git?
I counted approximately 20k diff lines (incl. context) between msysgit's
git master and git.git's master. At a first glance much of them seem to
be compatibility stuff.

	Steffen

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html