3

I am contemplating a jump into the Git bandwagon. My environment is made from 1-4 Windows client machines and a single FreeNAS server.

What do I need to make Git work in this type of configuration?

Is there any Git software that I need to install on the server? (in CVS, for example, I don't need to install any software, if the repository is accessed as a Windows (SMB) share).

What do I install on the client machine (Windows) if I already have Cygwin installed? Is there a pre-compiled git.exe (just like cvs.exe) which takes much less space than the proposed 130MB MSysGit?

Do I really have to go through compiling Git binaries in order to have Git on my Windows client?

I am totally clueless as to what the move from the CVS paradigm to the Git paradigm entails.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
WinWin
  • 7,493
  • 10
  • 44
  • 53

2 Answers2

3

Git is not the same as svn or cvs, since it is "Fully distributed", so there are not really clients and server, just nodes. In your case you'll want to get your "client machines" pointing to a remote repo on the NAS, where they can push their changes. You can point to this repo using many methods including file, as outlined here:

http://www.kernel.org/pub/software/scm/git/docs/git-push.html#URLS

In git all your clients are nodes too, so for example developer1 might have a experimental branch in his repo that developer2 pulls from to review. This branch would not need to be on the "server". This is both confusing and powerful.

The easiest start to to just follow the client/server model to start with. 4 "clients" pushing changes up to a git repo on a shared file server.

Is there a pre-compiled git.exe (just like cvs.exe)

Yes, look here, http://oreilly.com/software-engineering/excerpts/version-control-git/installing-git.html

I would also suggest signing up for a free github.com account, install git on one machine and play around, fork others projects, pull them down, push them up etc...

Maybe if you have an hour to kill buy the http://peepcode.com/products/git screencast to be walked though git.

macarthy
  • 3,074
  • 2
  • 23
  • 24
  • your answer was a true life saver. Thank you! (I don't have enough points to vote you up, but as soon as I have I will do so). – WinWin Feb 10 '11 at 13:17
3

On the computers in my shop, I simply:

  • unzip the portable edition of Git for Windows (from msysgit project); les than 10Mo (differs from the 130Mo msysgit downloads which allows to recompile Git on Windows: you don't need that for what you want to do).
  • change the <git install dir>/etc/gitconfig to add:
  • uses the <git install dir>/git-cmd.bat or the <git install dir>/git-bash.bat to open new DOS windows or bash sessions with the right PATH set in them (and in them only, meaning no global modification to the User PATH environement variable outside of those shells).
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @Benjol: for a server you need to add some kind of listener, unless you are using a simple [local protocol](http://progit.org/book/ch4-1.html#local_protocol) and are pushing to a share path. My server is a Solaris one and I use gitolite (meaning I use a secured shell ssh, and [forced commands](http://oreilly.com/catalog/sshtdg/chapter/ch08.html#22858) ). – VonC Feb 10 '11 at 06:27
  • @VonC Thank you, too. This is a great tip. – WinWin Feb 10 '11 at 13:18
  • Suggesting that people set `core.autocrlf` to `false` on Windows is just evil. Most people should use `input` instead of `false` unless they truly understand the difference and accept the risk of adding CRLFs to the history with `false`. – Arrowmaster Feb 10 '11 at 17:54
  • 1
    @Arrowmaster: I respect your point of view, but still am very much opposed to any kind of automatic conversion. Forcing 'lf' (the '`input`' setting) isn't always the solution of all data. – VonC Feb 10 '11 at 18:36
  • @VonC Its true that its not always the solution for all data, but its also true that the cause of almost all EOL problems in git is because of files treated as text files having CRLF line endings in the repo. If two Windows users have different autocrlf settings (false and input/true) then there will be problems as soon as the user with false commits something with CRLF line endings. The more proper solution is to set `* text=auto` in .gitattributes and then fine tune which files are detected as text files and which aren't with further .gitattributes lines if needed (like with UTF16/32 files). – Arrowmaster Feb 10 '11 at 20:08
  • @Arrowmaster: good and sound points. But since I'm the guy in charge to prepare the setups of all development tools (including standard text editors -- we are using notepad++ --, none of your developers have different settings ;) – VonC Feb 10 '11 at 20:22