Re: git on Cygwin: Not a valid object name HEAD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

On 8/10/07, Steffen Prohaska <prohaska@xxxxxx> 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!

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux