There's new GIT instructions on Github now

Jesse Phillips jessekphililps+D at gmail.com
Fri May 20 09:56:09 PDT 2011


Personally my experience has been adequate. But I don't put a great demand on what I need it to do. Most problem I had has just come from my misunderstandings, such as my recent use of submodules and path differences.

Don Wrote:

> Here's my list of bugs in git for windows which I found in the first 
> fews days of using it:
> 
> 1. Windows git's handling of paths is completely screwed.
> If you've checked out your working copy into (say) c:\foo\bar\dmd
> and you rename a parent directory, eg to c:\foo2\bar\dmd, your working 
> copy gets hosed.

May have done this without thinking about it, but I'd remember if I'd run into problems. I've tended not to move repositories and apparently just went straight to using git clone --bare to do it.

> Maybe this happens only after you've performed a git operation; didn't 
> experiment with it much.
> 2. It does something really horrible with the idea of your 'home' 
> directory. I'm not sure exactly what it does, but it seems to equate 'My 
> Documents' with $HOME. If ActiveDirectory is in use,
> you can end up with more than one $HOME. I've also had it suddenly think 
> that my home directory lies on a file server. This corrupts your 
> configuration file, and you lose your public keys.

I use GVim all the time, and I believe it sets up a HOME variable for you (or I did it myself so I can refer to it after installing Vim) but yes it will use My Documents if you don't have a Variable for HOME (my experience in the past).

Not sure if git will follow the rules, and I don't use ActiveDirectory myself (or don't know I am)

> 3. The 'gittutorial' is ridiculous and insulting. In the first two 
> minutes of using git, you already need to know far more commands than 
> are included in the tutorial. Most obviously, it should talk about 
> git-reset before discussing branching and collaboration.

I've used reset maybe 4-5 times in the past year, and have looked it up every time. Generally I'm just using git checkout .  and git stash.

> 4. If a large number of files have been changed in a single commit, gitk 
> can pop up a message box that is larger than your full screen -- so the 
> 'OK' button is not visible!

Never seen this, don't know if I've ever had a large enough change to make it happen.

> 5. TortoiseGit has a manual which is full of references to Subversion. 
> You cannot trust anything you read in that manual. I quickly gave up any 
> attempts to use TortoiseGit.

I prefer svn to TortoiseSVN so I've just stuck with git.

> 6. Git bash and/or vim is very amateurish. Eg, pressing cursor keys when 
> you're at the start of a line causes the screen to flash.

That is a feature of vim, it is the visual bell and tells you that the operation you preformed has no effect. Disable:

:set vb t_vb=""

http://vim.wikia.com/wiki/Disable_beeping_and_flashing

> 7. In git diff, using scroll bars to view an earlier part of the screen, 
> then pressing a key corrupts the bash screen.

gvimdiff is my diff program, don't have any issues.

> 8. Git diff's highlighting is wrong when a modified line is longer than 
> 80 characters long.

above

> You've really got to be a fanboy to claim that git is supported on 
> Windows. Sure, it "works" -- in the same way that hammering a nail with 
> a rock "works".

No, I just haven't had problems which have been related to it running on Windows.


More information about the Digitalmars-d mailing list