The Git Diff utility is much more functional than the standard command-line diff.

To see changes relative to the staging area (aka the index), use git diff.

To see staged changes, use git diff --staged (or --cached).

To see changes side by side on a line (where it makes sense), use the --color-word option.

To compare two arbitrary files in the file system, use git diff --no-index.

To try some other diff algorithms, use the --patience, --histogram, or --minimal options. The default diff algorithm is --myers.

Lots more at the docs.

Ever wonder what the six-digit file modes are in a Git commit? The mysterious 100644 and 100755 modes?

diff --git a/foo/bar.py b/foo/bar.py
old mode 100644
new mode 100755
index b829edea4..ee6bda024
--- a/foo/bar.py
+++ b/foo/bar.py
@@ -1,3 +1,4 @@
...

I had made foo/bar.py executable by using chmod +x and adding a #!/usr/bin/env python shebang. The last three digits are obviously the same octal digits that you can use with chmod. But what's that 100 prefix?

The ex­pla­na­tion can be found in a Stack­Over­flow answer:

100644₈  regular file (non-executable)  S_IFREG | S_IRUSR | S_IWUSR
                     

Ever had a Git repository where there's an over­whelm­ing number of branches, most of which are surely abandoned? You run git branch --remote and you see dozens of unfamiliar branches. Where to begin?

• Use git for-each-ref --sort to sort the branches so that you can identify the oldest branches.
• Use git branch --remote --merged master to detect which branches have already been merged into master. It's likely that these are branches that weren't deleted after a pull request was merged; it's usually safe to delete these.
• --no-merged shows unmerged branches; these require further in­ves­ti­ga­tion.

Here's an example for fly­ing­cloud:

$ git for-each-ref --sort=-committerdate \
    --format='%(committerdate:short) %(refname)' refs/heads refs/remotes
2016-12-29 refs/remotes/origin/master
2016-12-29 refs/remotes/origin/HEAD
2016-12-29 refs/heads/master
2016-12-11 

I learned today about the -v (--verbose) flag to git commit (git-commit), which causes a unified diff of what would be committed to be appended to the end of the commit message. This diff is not part of the commit. Set the commit.verbose con­fig­u­ra­tion variable (new in Git 2.9) to adjust the default behavior.

I also learned about using git show (git-show) to display the diff for the most recent commit. I had been using git log -1 --patch (git-log). More on git log -p vs. git show vs. git diff.

I needed to track down a remote branch created a couple of months ago on another machine. I knew which file had been changed, but none of the far-too-many remote branches' names rang a bell.

Turns out that using git branch --contains in the right way finds all the relevant branches.

git log --all --format=%H FILENAME \
    | while read f; do git branch --remotes --contains $f; done \
    | sort -u

The first line, git log --all --format=%H FILENAME, lists all the hashes for commits that contained changes to FILENAME. The second finds all the branches that contain those hashes (I added --remotes). The …continue.

[Pre­vi­ous­ly published at the now defunct MetaBrite Dev Blog.]

At MetaBrite, we believe in the power of pair pro­gram­ming. We find that pairing helps for col­lab­o­ra­tion on difficult tasks, for exploring new areas, for knowledge transfer, and for spurring each other to better solutions. I find it to be fun, though it can also be exhausting. It's not ideal for all our work—there's no value in tying up two developers on some rote task that both know well.

Last week, I rebuilt our primary pairing work­sta­tion. In its previous in­car­na­tion, we had an account for each developer. Each of us had set up some personal pref­er­ences in our own …continue.

As part of my personal conversion to Git, I read Swice­good's Git book. It's a decent in­tro­duc­tion to Git and you learn how to do all the basic tasks as well as some more advanced topics. The examples are clear and well-paced.

I would have liked to see more about col­lab­o­ra­tion and workflow in a DVCS world, perhaps a few case studies: how is Git used in the Linux kernel de­vel­op­ment process; how a small, dis­trib­uted team uses Git and GitHub; how a collocated team migrates from …continue.

In the last few weeks, I've switched over to Git for most of my version-control needs, at home and at work, after putting it on the long finger for months.

We continue to use Subversion at work, but I've recently followed Pavel and Eric's lead in using git-svn. I work locally on my own private branches and git svn dcommit and git svn rebase oc­ca­sion­al­ly. I'm primarily on Windows at work, but I have a Linux box and a Mac Mini too, while at home, I have a MacBook, a Linux netbook, and a Vista desktop. I'm using msysGit, oc­ca­sion­al­ly sup­ple­ment­ed by Tor­toise­Git and QGit. Pavel's on a Mac …continue.

At work, I've been ex­per­i­ment­ing with the big three Dis­trib­uted Version Control Systems, Git, Mercurial, and Bazaar, on Windows over the last ten days.

Pavel and Eric have been singing the praises of Git and git-svn on their Mac and Linux boxes re­spec­tive­ly for the last few months. Git allows them to check in small changes locally without perturbing the build. The ease of branching and merging allows them to work in more than one branch at a time at a lower cost than Subversion did. Most of our dev team continue to work in Subversion on Windows boxes. git-svn allows Pavel and Eric to easily in­ter­op­er­ate with the Subversion server. Pavel …continue.