Git

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

As far as I know, BitKeeper does not seem to support the notion of "local" (intra-repository) branches.

Git supports these, and I've found them very useful. With Git, you can easily have debug/test branches without the overhead or config issues of an entirely different repo. I've even used one branch per bug so I can have several things in the air before merging them into the master branch.

The only way I can see to do this in BitKeeper is to have separate repos, which wastes disk space and adds the trouble of creating and managing separate directory trees in the file system.

I'm more familiar with Git and its merge process, but I also use BitKeeper and sometimes run into merge conflicts. Here's some info on how to handle them.

Unlike Git, BitKeeper doesn't have the notion of "local" branches, so all merges are from push/pull operations. BitKeeper has a merge command, but it's for merging single files, rather than merging one local branch into another.