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
@@ -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 explanation can be found in a StackOverflow answer:
100644₈ regular file (non-executable) S_IFREG | S_IRUSR | S_IWUSR
Ever had a Git repository where there's an overwhelming 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 investigation.
Here's an example for flyingcloud:
$ git for-each-ref --sort=-committerdate \
--format='%(committerdate:short) %(refname)' refs/heads refs/remotes
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 configuration 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 …continue.
[Previously published at the now defunct MetaBrite Dev Blog.]
At MetaBrite, we believe in the power of pair programming.
We find that pairing helps for collaboration 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 workstation.
In its previous incarnation, we had an account for each developer.
Each of us had set up some personal preferences in our own …continue.
Title: Pragmatic Version Control Using Git
Author: Travis Swicegood
Rating: ★ ★ ★ ★
Publisher: Pragmatic Bookshelf
Reading period: 10–18 October, 2009
As part of my personal conversion to Git, I read Swicegood's Git book.
It's a decent introduction 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 collaboration and workflow in a DVCS world,
perhaps a few case studies:
how is Git used in the Linux kernel development process;
how a small, distributed 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 occasionally.
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, occasionally supplemented by TortoiseGit and QGit.
Pavel's on a Mac …continue.
At work, I've been experimenting with the big three
Distributed 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 respectively
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 interoperate with the Subversion server.