There are TortoiseCVS, TortoiseSVN, TortoiseBzr, TortoiseHg
Why not ToroiseGit
 
best regards
Frank Li
--

[ message continues ]

Because GitCheetah

-- 
Jakub Narebski
Poland
ShadeHawk on #git
--

[ message continues ]

GitCheetah seem only GitGui Here and GitBash Here. 
TortoiseXXX can show log, diff, commit change ...at explore menu. 

Best regards
Frank Li 

-----Original Message-----
From: Jakub Narebski [mailto:jnareb@gmail.com] 
Sent: Friday, October 31, 2008 9:59 AM
To: Li Frank-B20596
Cc: git@vger.kernel.org
Subject: Re: why not TortoiseGit


Because GitCheetah

--
Jakub Narebski
Poland
ShadeHawk on #git
--

[ message continues ]

The very very blunt answer is, TortoiseGit doesn't exist because no
one has created it. And this may partly be do to the fact that git is
more powerful then the programs who have it, so its a bigger project
to make it stupid proof.

-G

--

[ message continues ]

... and from what I've seen of tortoise* users, "stupid proof" is very,
very, very, necessary...

-Miles

-- 
Immortality, n.  A toy which people cry for, And on their knees apply for,
      Dispute, contend and lie for, And if allowed Would be right proud
      Eternally to die for.
--

[ message continues ]

This is what Johannes Schindelin had to say,

	<http://code.google.com/p/msysgit/wiki/GitCheetah>
--

[ message continues ]

Noone's written TortoiseGit yet. I have no idea why, and I have
no reason to write it myself. If GitCheetah isn't working well,
I'm sure patches are welcome.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
--

[ message continues ]

I'm trying to get this restarted - dscho and I talked about this at
the GitTogether, and I met some people (from the OpenAFS project that
also happened to be there, oddly) who were interested in working on
this with me.  I think the lack of a linkable library has greatly
hindered the development of projects like this, so that will likely be
part of the development process as well.

Scott

--

[ message continues ]

I read some code of TortoiseSVN and TortoiseHg Code. 
At beginning, TortoiseGit can git command to get information like Qgit.
After linkable library ready, replace "git command". 

I think TortoiseGit can start base on below way.
 
1.  Base on TortoiseHg, It is python Script.  Replace below hg operator
with Git. 
2.  Base on TortoiseSVN, It is developed with C++. Need VS2008.
ToritoiseSVN provide some built in diff and merge tools. 
3.  Base on Qgit, which provide some basic UI, such comment dialogbox,
history view and file annotate. 


Best regards
Frank Li

-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
Behalf Of Scott Chacon
Sent: Friday, October 31, 2008 11:58 PM
To: Andreas Ericsson
Cc: Ian Hilt; Li Frank-B20596; git@vger.kernel.org
Subject: Re: why not TortoiseGit

I'm trying to get this restarted - dscho and I talked about this at the
GitTogether, and I met some people (from the OpenAFS project that also
happened to be there, oddly) who were interested in working on this with
me.  I think the lack of a linkable library has greatly hindered the
development of projects like this, so that will likely be part of the
development process as well.

Scott

--

--

[ message continues ]

TortoiseSVN is a good place to start because it separates out the
windows icon decorators into a separate DLL (shared with TortoiseCVS).
This is significant, as these are a finite resource in the windows
shell, and so having a TortoiseSVN + TortoiseGIT on one machine and
you might run out, and I'd imagine lots of people wanting both.

On the minus side, building (Tortoise)SVN requires a lot of
environment setup just to get it to build - most of which can be
immediately thrown away as it's specific to SVN.

But it doesn't look like a hard project to me, just requires stripping
out a lot of junk and re-patching callouts to a git executable (which
could be the standard git tools) and a minimal git library that knows
if files are dirty.
--

[ message continues ]

Hi,


I only wish that people would put their code where there mouth is.

At least with GitCheetah, we have working code, _and_ an opportunity to go 
cross-platform.

Ciao,
Dscho

--

[ message continues ]

Well, hey, I don't care there's no TortoiseGit. I looked at these
things back when I had colleagues stuck on Windows, and at the time
wanted to try and wean them off SVN.

The shell-icon overlay limit on Windows looked a significant problem
to me, and a good reason for at least re-using that bit of code (which
is common to even tortoiseCVS). It looked like it had been through a
significant number of iterations to get platform shell subtleties
right.

I even looked at wacky things, like using IKVM.Net and JGit to hack it
quickly, but that's a non-starter because of MS' stupid
one-clr-per-process.

That's what I found. Maybe it'll be useful for anyone else that wants
to continue. Since it's not an itch for me any more, and it won't feed
my children, until someone that cares enough does something there
won't be one.
--

[ message continues ]

I also think it is best choose base on Tortoise SVN.  TortoriseGIt
should be in windows platform only because it is extension of explore.

Best regards
Frank Li 

-----Original Message-----
From: Nigel Magnay [mailto:nigel.magnay@gmail.com] 
Sent: Monday, November 03, 2008 6:00 PM
To: Li Frank-B20596
Cc: Scott Chacon; Andreas Ericsson; Ian Hilt; git@vger.kernel.org

TortoiseSVN is a good place to start because it separates out the
windows icon decorators into a separate DLL (shared with TortoiseCVS).
This is significant, as these are a finite resource in the windows
shell, and so having a TortoiseSVN + TortoiseGIT on one machine and you
might run out, and I'd imagine lots of people wanting both.

On the minus side, building (Tortoise)SVN requires a lot of environment
setup just to get it to build - most of which can be immediately thrown
away as it's specific to SVN.

But it doesn't look like a hard project to me, just requires stripping
out a lot of junk and re-patching callouts to a git executable (which
could be the standard git tools) and a minimal git library that knows if
files are dirty.
--

[ message continues ]

Hi,


FYI I completely disagree with this reasoning.

Ciao,
Dscho

--

[ message continues ]

Nigel Magnay:

I create a tortoisegit project at repo.or.cz. 
http://repo.or.cz/w/TortoiseGit.git

It is coming from TortoiseSVN. It is very early stage.  The context menu
have worked.  TortoiseGitProc.exe help command have been worked.  

Welcome contribute. 

Best regards
Frank Li

-----Original Message-----
From: Nigel Magnay [mailto:nigel.magnay@gmail.com] 
Sent: Monday, November 03, 2008 6:00 PM
To: Li Frank-B20596
Cc: Scott Chacon; Andreas Ericsson; Ian Hilt; git@vger.kernel.org

TortoiseSVN is a good place to start because it separates out the
windows icon decorators into a separate DLL (shared with TortoiseCVS).
This is significant, as these are a finite resource in the windows
shell, and so having a TortoiseSVN + TortoiseGIT on one machine and you
might run out, and I'd imagine lots of people wanting both.

On the minus side, building (Tortoise)SVN requires a lot of environment
setup just to get it to build - most of which can be immediately thrown
away as it's specific to SVN.

But it doesn't look like a hard project to me, just requires stripping
out a lot of junk and re-patching callouts to a git executable (which
could be the standard git tools) and a minimal git library that knows if
files are dirty.
--

[ message continues ]