Git

• To search content of all tracked files in the current working tree for a pattern:

  git grep <regexp>

• To search content of all commit messages for a pattern ('-E' for extended grep):

  git log [-E] --grep <regexp>

• To search content of all commit diffs for lines that add or remove a pattern ('-w' for pattern only at word boundary):

  git [-w] log -G<regexp>

• To search content of entire working trees of previous revisions for a pattern:

Merge conflicts suck. It is not uncommon, however, that you often just know that you really just want to accept all the changes from the branch that you are merging in. Which makes things a lot simpler conceptually. The Git documentation suggests that this can also be procedurally simple as well, as it mentions the "-s theirs" merge strategy which does just that, i.e., unconditionally accept everything from the branch that you are merging in:

Git offers two ways of viewing differences between commits, or between commits and your working tree: diff and difftool. The first of these, by default, dumps the results to the standard output. This mode of presentation is great for quick summaries of small sets of changes, but is a little cumbersome if there are a large number of changes between the two commits being compared and/or you want to closely exa

Ideally, you could refer the whole world --- or at least, the significant portion thereof that want your code --- to your (public mirror) Git repository. But unfortunately, the whole world does not (yet) use Git ("I know it was you Fredo, I know it was you, and it breaks my heart."). Sad. Sooooo sad. But true. So the only recourse is for you to send these tortured souls an archived snapshot of your code via e-mail. I'll pause now to let you finish retching/sobbing/lamenting/venting. ... Back? Anyway, Git has a neat "archive" command that helps you create the required archive, but perhaps it does not have the most friendliest interface in the world. I've written some scripts to wrap the Git command to facilitate its use, which I share here.

.gitattributes export-ignore
.gitignore export-ignore
*.tmp export-ignore

Part 1 of this article described a standard development workflow using Git that took advantage of the distributed nature of the system to maintain a code base across two or three different repositories, including a primary shared "working" code repository and a development "work-in-progress" code repository. Some aspects of this workflow are tedious and reptititive, while others, such as the management of different branches in different repositories can make housekeeping a little more complex. In this, the second part of the two-part series, I present a few simple scripts or tools that, when incorporated into the development ecosystem, go such a long way in alleviating these problems that the whole process quickly becomes a seamless and natural part of the standard routine.

Repository Setup

For most major projects, I have at least two, and sometimes three, remote Git repositories upstream of my local one:

With multiple upstream repositories and branches, and different branches on different upstreams, an enhanced "log" view will help greatly in taking stock of everything.

When you pull and update your local, it would be nice to easily see all the commits that you have applied in the pull. Sure you can figure it by scanning through the git log carefully, but adding the following to your '~/.gitconfig' gives you an easy way to see it in a glance:

The following will enable you to have a Git-aware "cd" command with directory path expansion/auto-completion relative to the repository root. You will have to source it into your "~/.bashrc" file, after which invoking "gcd" from the shell will allow you specify directory paths relative to the root of your Git repository no matter where you are within the working tree.

Here are three confessions: