luhman.org

Running PHP's "built-in" lint checker (php -l) is a quick way to remove syntax errors which should never creep into your code.

However, you'll no doubt soon tire of typing "php -l" before every Git commit message, so why not let Git do the checking for you with a "pre-commit hook".

Travis Swicegood has a great article on how to set this up with Git :
http://phpadvent.org/2008/dont-commit-that-error-by-travis-swicegood

I found you could pretty much copy his pre-commit PHP script and paste it into your .git/hooks directory with a couple caveats :

In this post, I'm just trying to get the simplest setup. I'll try to post details in a subsequent post.

Here are three posts, in descending order, on this that I found useful :

http://toptopic.wordpress.com/2009/02/26/php-and-hudson/

http://blog.jepamedia.org/2009/10/28/continuous-integration-for-php-with...

http://www.davegardner.me.uk/blog/2009/11/09/continuous-integration-for-...

First, I had to install java :

    $ sudo aptitude install sun-java6-jre  

I had a case where I had to build Git on an older Red Hat based system. Unfortunately, the system was so old that yum wasn't really supported. So I had to install the needed libraries (RPMs) "by hand" via rpm -i. There was one package that I had to update via rpm -U.

On my rather bare system, I found I had to install the following RPMs to get Git to compile :

cpp
curl
curl-devel
e2fsprogs-devel
gcc
glibc-devel
glibc-headers
glibc-kernheaders
krb5-devel
krb5-libs
make
openssl
openssl-devel
wget
zlib-devel

I had some patches in one Git repository that I wanted to apply to a different repository. Here's a useful link I found on this :

http://stackoverflow.com/questions/327249/seeking-examples-of-workflow-u...

Here's what I did.

First, copy the original repository you want to get patch from. This may not be necessary in all cases, but in my case the original repository was on another machine, so this just puts everything on the same machine.

  
    $ git clone ssh://me@example.com/repos/origRepo
    $ cd origRepo

For the most part, I use TkDiff as the Git difftool when working under X Windows. TortoiseGit also has a nice GUI diff tool for when I do occassional work on Windows.

However, when working in a Linux "terminal" environment, your Git difftool choices seem to be limited to vimdiff. This is OK, but most of the color schemes under vimdiff are terrible.

I recommend using a vimdiff friendly color scheme like "greens" which is described here :
http://www.vim.org/scripts/script.php?script_id=1253

Here's how to set yourself up to use vimdiff as Git's difftool.

I'm using the DNS-323 primarily for automated backups, and making Git backups is part of this. The fonz fun plug (ffp) has a lot of stuff on it (rsync, lighttpd), but I didn't see Git. So I was looking to add Git via Optware.

I was able to add Optware, but the Git version couldn't clone across ssh nor rsync. Cloning across the git protocol did, however work. But I'll likely just use the rsync client to get my Git repositories. Git seems to work fine if the repo came via a plain rsync client.

root:/mnt/HD_a2/tmp# git clone ssh://root@192.168.1.108/tmp/gitTest

As I've mentioned before, Git push takes some getting used to. Issuing the simple command "git push" may not give you what you expect.

I've kind of gotten used to using git fetch to pull into FETCH_HEAD, and then seeing if I want to merge FETCH_HEAD into master. Here's the analog when pushing.

First, let's assume we're pushing into a Linux repository from a Windows client. Our Linux repo has just two files initially:

Linux

@linux:/tmp/gitTest (master#) $ git commit -a -m "Initial commit"

I'm looking to find a way to retain, access, and analyze files which come in over time. One part of a solution to this may be using a free, efficient file version control system (VCS) like Mercurial or Git.

One way to track file updates is to save multiple copies of a file for a limited time. However, itt should be more more space-efficient to have a VCS merely save diffs in the files. A VCS would also aid in tracking exactly when a certain change was made.

My own personal cheat sheet of useful Git commands.

diff

git diff --stat --staged (staged in 1.6+, cached in older)

Differences between HEAD and index (i.e., shows changes that have been staged)

git diff -U1 --stat

Reduces the context lines around differences to one line for shorter display. Puts summary (stat) at start of diff.

Here are especially helpful Git links :

Git Index (Staging Area)
Good layman's view of the index, along with great images of how add, commit, diff, push, fetch work.

• http://osteele.com/archives/2008/05/my-git-workflow

Git Cheat Sheet
A bit laconic, but a comprehensive overview of most all useful commands, with reasonable examples.

• http://cheat.errtheblog.com/s/git

GitReady.com
Lots of hints for beginners and experts.

• http://gitready.com