A short note on Cygwin git

I use git for my source control, and when developing under Windows, I use the Cygwin environment for all of my command line needs.  My background is primarily Unix, so I'm used to having a powerful shell prompt and scripting for a lot of tasks.  I also use the git available from Cygwin instead of the one from the git site.

You will quickly run into execute permission problems and CRLF vs. LF translation problems.

Execute bit

Windows doesn't manage the execute bit very well, especially on a FAT filesystem, but I find it even on NTFS.  Files created under Cygwin will be created according to your umask, usually as mode 0644, while files from Windows will show up as 0700.  This isn't a real problem except that git tracks the mode of each file in the repository, so changes to the mode will show up as the file being modified.  Setting core.filemode to false tells git to ignore the executable bit.  If something slips in, you may have to use git update-index --chmod=-x to correct it.

core.filemode is set in your .git/config file by git init regardless of how it's set in your system or global configuration, so you will need to set it in your repository configuration.

CRLF vs. LF

Files created under Cygwin will use only LF to mark end of line, while files created under Windows applications will use CRLF.  By setting core.autocrlf to true, Cygwin git will convert all CRLFs to LFs on commit operations, and all LFs to CRLFs when checking out.

I also set core.safecrlf to warn, which checks, before adding a file, that doing the crlf conversions is "safe".  We want to make sure that we'll get the same file back when it's checked out.  Git cannot "safely" convert files that contain both LFs and CRLFs, so a file that's been edited under both Windows and Cygwin may produce warning: LF will be replaced by CRLF in Foo.java when running git add.  This is not a problem with text files, because the file will be cleaned up during its next commit so that all EOLs are the same.  However, binary files will be corrupted if they are not properly detected by git.  I have never seen git label a binary file as text, but if this does occur you can set the file in .gitattributes as binary.  For example

   *.jpg binary

will make git consider all .jpg files as binary, and will not apply the CRLF conversion, nor will it try a text diff.  

You can also set core.safecrlf to true instead of warn, in which case the error will be fatal, and you will have to correct the problem before you can add the file.  You can run a text file through unix2dos, or add the binary file to .gitattributes, but since git bats a thousand, in my experience, at detecting binary files, it's a waste of time to have to manually fix all of your text files.

TL;DR

So in conclusion, if developing using git under Cygwin, I run the following commands after creating a repository:

   git config core.autocrlf true
   git config core.safecrlf warn
   git config core.filemode false

Explanations of these settings can be found on the git-config man page.

In the beginning...

What's all this then?

I need to bring my web development skills up to date, instead of living in the all raw-HTML-only-static-pages past.  After doing some research, I liked what I read about Google App Engine (GAE), as well as Google Web Toolkit (GWT).  Especially that, right now, it will let me focus on the code instead of managing the servers.

Oh, and I can use Java for both the client and server.

I volunteer at a local non-profit, where volunteers track their time with pen and paper, and our contact information is gathered once when we sign up, and then never updated.  The hours have to be manually transcribed into a spreadsheet, and it makes it hard to run reports or gather statistics.  This seemed like an ideal project that shouldn't take forever, but also should get into the meat of the two products.

OK, but what's the deal with the blog?

Sometimes I work late, and have trouble remembering the next day exactly what I had tried, what research I had done and its conclusions, or just where I am in the project.  I usually document this stuff in a text file.  While researching best practices for GAE/GWT, I wanted a site that chronicled the creation of an application from the beginning.  Initially I didn't find any.  I based my knowledge of best practices on the famous and excellent Google I/O talk: GWT App Architecture Best Practices by Ray Ryan.  It's invaluable.

Later, I did come across a GWT/GAE Development Blog that seems like a good introduction, though I haven't worked through much of it yet.  I'm sure I'll use it as a reference as I learn.

But I want to chronicle the fits and starts, both the good and bad ideas, the failures, the dead ends, the screw ups; and then hopefully successes.

Basic project details

I haven't decided on a name yet, so I'll just call it "the project" for now.  It will be hosted on github, as I like git's branching and DCVS model.  I'll use Java in Eclipse Helios as the language, but still access git from the command line, since I've had plenty of problems with the git plug-in.  I will probably use the Gin and Guice libraries, and base my MVP design around the gwt-presenter and gwt-dispatch libraries, though they look like they haven't been updated in a while.

For testing the pages I'll use the Google plug-in for Eclipse, as well as the Speed Tracer, Firebug, etc.

Enough procrastinating...