Git

Grepping in Git: How to Search Git Repository Revisions, Working Trees, Commit Messages etc.

Submitted by Jeet Sukumaran on

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

    git grep

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

    git log [-E] --grep

  • 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

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

Unconditionally Accepting All Merging-In Changes During a Git Merge

Submitted by Jeet Sukumaran on

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:

Setting Up Git's difftool to Use Your Diff Viewer/Editor of Choice

Submitted by Jeet Sukumaran on

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 examin

Easily Create (Clean) Compressed Tarballs of Your Git Repository

Submitted by Jeet Sukumaran on

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.

Update 2011-07-07: I have re-written the original three scripts previously described here as a single script, incorporating some of the excellent suggestions that kind folks provided in the comments. Immediately below this is the new, unified, all-bells-and-whistles-included script. Simply name it something like "git-makedist", switch on its executable bit, and place it somewhere on your system path. Reasonable names, filepaths, prefixes, etc. are all provided if you do not explicitly specify them. All of which means that, in most cases, once installed, simply invoking the command "git makedist" without any options or arguments from within a Git repository "just works (tm)", resulting in a sensibly-named compressed archive of the current HEAD ready for distribution. At the same time, various flags and options allow you to fine-tune the operations, e.g. determine the compression/archive method, the path prefixes, the archive name, etc.

Update 2011-07-22, Excluding Files: Sometimes, not all files need to make it out to an archive. You can use the ".gitattributes" file to control which files get archived. Simply add the paths/names/globs of the files or directories you would like to exclude, and add a "export-ignore" after it. For example: 

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

Note that the ".gitattributes" file has to be committed for it to have an effect.

Development Workflow with Git, Part 2: Scripts and Tools to Facilitate the Workflow

Submitted by Jeet Sukumaran on

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.

Enhanced Git Log View Showing Symbolic References Associated with Each Commit

Submitted by Jeet Sukumaran on

With multiple upstream repositories and branches, and different branches on different upstreams, an enhanced "log" view will help greatly in taking stock of everything. Adding the following line to your "~/.gitconfig" will give you a new command, "git slog" (for "short log") that does just that:

'gcd' : Git-Aware 'cd' Relative to Repository Root with Auto-Completion

Submitted by Jeet Sukumaran on

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.

Pages

Subscribe to Git