Version Control
Cleaner Git Log With Merges
In some of our repositories now, Panhandler in particular, there are a lot of merge commits. As the master branch containing the API definition gets updated, each driver branch merges in master so that it can be updated to target the latest API. This results in the driver branches having various merge commits that bring in master, and that can make the output of a simple ‘git log’ more verbose than you may want. One useful option for git-log is ‘--no-merges’, which will omit any merge commits. If we have a repo like this O---O---A---B---C---D---E---F [master] \ \ O---O---G---H---I---J---K [driver] and we run $ git checkout driver $ git log --no-merges then we won’t see commits G or J, since those are points where master was merged into the driver branch. But one issue is that ...
1 Comment | Posted in Project Management,SDLC,Version Control,blog
June 15, 2010
More Info From Git Branches
For those of you that follow our posts on a regular basis, you'll know we are somewhat biased toward using Git for version control. While Git takes some getting used to, once you have the basics down it is a very powerful tool. As you become more familiar with Git, you start to realize there are quite a few "power tools" available to you that let you delve deeper into the history of your project. The following article posted by Eric Ritz on our corporate mailing list provides yet another useful tip on how to get more from Git. Enjoy! - Lance Something I don’t see advertised very much is the fact that git-branch has a verbose parameter: ‘--verbose’, or just ‘-v’. This parameter will show you which commit each branch is ...
0 Comment | Posted in Version Control,blog
June 10, 2010
Working With Git
Here are some basic cheat-sheet style hints for working with the git version control system. Creating A Repository These are the steps for starting a new repository with git. The commands here assume you will be working with a group of people that all need access to the repository from your server. You will need command line access to the Linux shell to do this. In our example we assume our developers all belong to the user group "dev" on the Linux box and our storage of the git repositories is in the /devdir/gitrepos directory. Log in as a user who belongs to the dev group. Make your way over to /devdir/gitrepos. Create the directory for your project. Make sure it ends with .git, e.g. wego.git. Go inside the directory you just made. Enter git --bare init --shared=group Finally do a ...
0 Comment | Posted in Project Management,SDLC,Version Control,blog
May 10, 2010
Versioning Word Documents In Git
At first I didn’t know if I should write this email. I really, really, really do not like dealing with Word documents. It has nothing to do with Word specifically as a product; I hate documents in that kind of format in general, including the stuff OpenOffice.org produces. I don’t like working with WYSIWYG documents, at all. One argument I can make against using Word files on projects is that you can’t meaningfully put them in a repository. Well—this isn’t true. You can do it, and actually do things like diff Word documents. So ultimately I decided it is more helpful to share this information than to secretly hide it in an attempt to keep people from using that God awful format. Of course, I’m going to regret it as soon as there’s some Word document in one of the repositories… A rarely used feature ...
0 Comment | Posted in Tips & Tricks,Version Control,blog
March 12, 2010
Basic Overview of Bare Git Repositories
During a meeting yesterday we were talking about our internal repo library and reading some file out of all of the repositories for the purposes of generating some type of overview page. And it was mentioned that this would be a little tricky since all of the Git repositories would be “bare repositories.” I want to explain want that means. A bare repository is one with no working tree. That is, there is nothing checked out. At the top level of every repository you will find a ‘.git’ directory. If you made that directory the only one in the repository, then that repository would be bare. This is the reason why it is convention for bare repository directories to be named ‘foo.git’, since when you clone them they are the contents of ‘/foo/.git’. For example, here is a bare version of the a project database interface ...
0 Comment | Posted in Version Control,blog
February 23, 2010
Undoing Mistakes Easily in Git
When I was explaining Git stuff to a co-worker on Friday, I said, if anything ever goes wrong to just remember this to undo it: $ git checkout @{1} I told him that would put him back in the state he was in prior to whatever his last command was. Although then I did not go on to give a full, technical explanation of the cryptic command, as I did not think he needed to know it; I rarely need to understand the mechanics of a safety device in order to benefit from it. But here I’m going to explain what this odd looking command is really doing. And it is worth remembering. Whenever the tip of a branch changes—maybe you make a commit, or reset something, or simply checkout another branch—Git records that change in something called the reflog. You can run the command git-reflog in any repository to get ...
0 Comment | Posted in Project Management,Version Control,blog
February 14, 2010
Commit Templates
On a lot of our commit messages we add a ‘Redmine-Ticket’ line with the appropriate ticket number. On some projects we also add a ‘Version’ line naming the build for which that patch is associated (using tags would be better for that in my opinion, but that’s a different subject). So most commits on one project have two lines like so: Redmine-Ticket: 1763 Version: 6.80 Typing that over and over can get old, but fortunately it can be automated. Git allows you to specify a template file for commits, which you can do globally or per-repository by configuring the value of ‘commit.template’, which should name the template file. Let’s say I make a file called ‘ProjectCommit.template’ with these contents: Redmine-Ticket: Version: 6.80 Then I can do this inside the repository: git config commit.template ‘ProjectCommit.template’ Now whenever I commit anything, Git will automatically use the contents of that file as my initial commit message, which ...
0 Comment | Posted in Project Management,Version Control,blog
February 12, 2010
Version Control Your Home Directory
Git is useful not only for working with software projects, but also for keeping a history of things in your home directory. If you're on Linux, then I recommend putting your entire home directory under Git. And if you're on Windows, put the most appropriate directory under version control. At first this may sound a little off the wall. However, I am not recommending that you track everything. In fact, I suggest that you very carefully pick and choose what you want to track. This is what I did: after initializing the repository in my home directory, I opened the file .git/info/exclude and added this: # Ignore everything * Which tells Git to ignore everything in my home directory. Then after that I added specific rules to un-ignore the files I was interested in. You can do this by prefixing the filename with the '!' character. For example: # Ignore everything * # But save my ...
0 Comment | Posted in Version Control,blog
January 22, 2010
Git: Version 1.6.6
The next major version of Git---1.6.6---should be out any day now. At which point I will let you guys know. But I wanted to go ahead and tell you about the changes to take note of. git-config In your config files, variables that take paths can begin with ~/ or ~user/ and will be expanded as expected. Something that caught Chris out today, actually. git-checkout If the remote repository has a branch called 'foo', and you do not have a local branch called 'foo', then the command: $ git checkout foo will create and checkout a local version of the remote branch. It will be the same thing as currently doing: $ git checkout -t origin/foo. git-fetch There are a few new options to this command, but one really important one: --prune. In Git 1.6.6 you can run: $ git fetch --prune origin which does the same thing as: $ git fetch origin && git remote prune origin git-merge Has a new option: --ff-only. ...
0 Comment | Posted in Version Control,blog
January 20, 2010
Using a Git Excludes File
Within a Git repository you can ignore files either by adding them to a .gitignore file, or by listing them in .git/info/excludes. The second option is useful for ignoring files which are particular to your copy of the repository. For example, I use Emacs for editing and often have two Emacs-related files in each of my repositories: .emacs.desktop and TAGS. I list these in .git/info/excludes to keep them out of the repository, but I do not include them in a .gitignore because other people probably will not have those files to begin with. However, it gets old ignoring those files again and again, for each new repository. Fortunately Git provides a way of automating that. First you need to create a file that listes all the files you would like to ignore in each new repository. For me this file is /home/eric/.gitexcludes and it ...
0 Comment | Posted in Version Control,blog
November 10, 2009
