GitX mailing-list

We’ve been using our Lighthouse tracker to respond to bugs and to discuss features for quite a while now. Email exchanges between Pieter and other contributors were getting more common, so we decided to open a mailing-list for GitX. We already got some nice patches through the list, which has the great advantage that patches can easily be reviewed inline and discussed. The use of the GitHub-wiki is discouraged, as is the Pull-request functionality.

GitX survey

To accompany this release, and to improve the input from our users, we have created a small (< 5 min) survey for GitX. We’d be happy if you took the time to go through it. Link to the GitX user survey

The juicy details after the jump:

Operations on hunks/lines

Staging and unstaging hunks has been possible for some time. What’s new is the “Discard Hunk” button which simply gets rid of that change, i.e. uses apply –reverse. As usual, the warning-box that shows up can be silenced by Alt-Clicking the button.
The most obvious change is the ability to stage specific lines from a hunk, using the left mouse-button to drag-select a few lines and then hit “Stage lines”. This is by far the most advanced method to stage stuff in a git-gui up until now.

History

Two small changes that should make life easier are the orange color for you current branch in the rev-list and the menu-title, which displays your current HEAD as well.
The panes which hold the list of commits and the individual diffs can now be collapsed/uncollapsed using double-click or the keystroke “Command-Shift-Up/Down”. This gives you the ability to quickly maximize complicated history or diffs.

Committing

The commit-view gained a “Sign-Off” button. Commits keep their author information when amending. And the (Un)staged-changes list gained a “Show in Finder” menu item. The diff now shows the committer, who can be someone other than the author of a patch. Commit-hooks now get executed upon committing.

General

A small preference called “Show white-space differences” shows you diffs with white-space-only changes. We also tried to make most of the alert-messages run non-modal, which means they won’t block other instances of GitX. The tree-view doesn’t try to display the content of binary-files anymore. Furthermore we updated a few passages of the UserManual to reflect the current state of GitX.

Bugfixes

The big heap of stuff were bugfixes, some trivial, very few regressions, some simply annoying and some features to protect users from doing harm to themselves. A few of those fixes were performance-related, and with the new Safari 4 the diff-view should suffer less.

What’s in the pipeline for GitX 0.8

One of the changes that almost made it to GitX 0.7 is the auto-refresh feature, which monitors the repository and reloads GitX automatically when something is changed. We’re confident that this feature will be in 0.8, if not earlier.

Diffstat/shortlog

Shortlog:

Benjamin Kramer (9):
      HistoryView: Factor out email formatting
      HistoryView: Show committer if his name differs from the author's
      HistoryView: Show commit date
      HistoryView: Make table header large enough so the text doesn't shift
      Don't compile plain ObjC files as ObjC++
      Get rid of some unnecessary casts
      Remove a .DS_Store
      Fix an obvious typo
      Fix checkbox scaling warnings

Benoit Cerrina (1):
      PBGitRepository: Fix opening of large directories due to bug in NSFileWrapper.

Charles O'Rourke (2):
      Ticket #142: Add Show in Finder to Unstaged and Staged table views.
      Tickets #151 and #155: check for illegal branch names before creating.

Gerd Knops (1):
      Fix build with external build products directory

JD Smith (4):
      commit view: Ensure buttons display on top of text ... but beneath title line.
      diffHighlighter.js: Record the line index as attribute.
      commit.js: Refactor hunk retrieval. To work with subhunks, allow passing a header line explicitly to search for.
      commit.js: Interface for selecting lines to (un-)stage.

Joe Fiorini (3):
      Write commit message to file
      Enable arguments to be passed to executeHook.
      Trigger commit-msg hook when committing

Johannes Gilger (31):
      GitX: Make toolbar in history and commit view equal height
      Info.plist: Fix handling of directories
      PBGitCommit: Call git show with --no-color to be safe
      PBGitRepository: Display branch-name in window title
      PBGitRepository: Correctly indicate bare/non-bare repos
      history.js: Fix display of mode-change and rename
      PBGitCommitController: Fix unstaging of files
      PBWebChanges: Allow discarding of hunks
      PBGitRepository: Add method to remove branch
      PBGitWindowController: Use beginSheetModalForWindow instead of runModal
      keyboardNavigation: Fix keys 'c' and 'v' from webView
      PBGitCommit: Add "Sign-Off" button/method
      PBGitCommitController: Don't allow duplicate Sign-Offs
      PBGitHistory: Add "Show in Finder" to files
      PBGitIndexController: Renamed "Revert" to "Discard"
      Add PBCollapsibleSplitView as subclass of PBNiceSplitView
      PBCollapsibleSplitView: Enable collapse/uncollapse using keys
      Statusbar: Bring View-Mode buttons to front
      Keep window-title up-to-date in commit view
      commit.js: Fix discardHunk functionality
      This fixes a CSS-bug which makes the gitx-website display the same font with Firefox and Safari instead of using a serif with FF.
      Add empty line at end of previous release notes
      UserManual: Add disclaimer as to what GitX is
      GitX 0.7 Release-Notes
      UserManual: Add disclaimer as to what GitX is
      UserManual: Rewrite most parts for GitX 0.7
      About-Panel: Show git-describe using Info.plist
      Site: W3C-Valid and CSS/HTML corrections
      ReleaseNotes for v0.7 with author information
      Site: Get rid of auto-refresh description
      PBGitTree: Don't try to print binary-file contents

Mike Czepiel (1):
      Added very basic tag info menu item and alert.

Nicholas Riley (6):
      Reduce font size of staged/unstaged changes lists.
      Don't disturb editing state when inserting "Signed-off-by" line.
      Remove extraneous space in "Are you sure you wish to revert changes?" message.
      Set keyboard focus reasonably when switching between views.
      Clean up UI and add keyboard support for create branch sheet.
      Truncate the middle of pathnames in the Unstaged/Staged Changes lists.

Pieter de Bie (51):
      Update diffHighlighter test
      HistoryView: speed up diff display
      Allow executing of hooks
      Trigger pre and post-commit hooks when committing
      CommitController: Don't rewrap commit message when amending
      Allow a user to select which columns to display
      HistoryView: Autosave column information
      GitRevList: fix crash when loading 0 commits
      GitRevList -- Try to read the encoding of the commit message
      GitRevList: cache the values of string encodings
      GitRevList: Use std::map.find() rather than count()
      GitCommitController: clean up index functions
      CommitController: Use a dictionary lookup when refreshing index
      GitCommitController: Also use dictionary lookup for untracked files
      PBChangedFile: remove shouldBeDeleted boolean
      Rename 'CachedChanges" to "StagedChanges" for greater consistency
      Add an example of how drag-selection for staging lines could work.
      HistoryView: Resize the detail webview
      Site: add link to Twitter
      PBEasyPipe: Add method that allows you to specify the environment stuff
      PBGitRepository: Specify environment when calling hooks
      PBGitRepository: Add support for changing the environment when executing commands
      NSSTring_RegEx: Add support for regular expressions to NSString
      PBGitCommitController: retain author information of previous commit
      Preferences: Resize views
      Add preference to ignore whitespace differences in history view
      CommitController: don't mutate array we enumerate when refreshing index
      HistoryView: only add parents if parents array exists
      Site: update links to reflect move to mailing list
      Remove use of deprecated stringWithCString
      PBGitConfig: Add missing sentinel
      CommitController: Notify observers when adding files
      History fileview: select current item on rightclick
      Display context menu in the history tree to show related commits
      HistoryController: Add some marks
      WebHistoryController: Refactor menu search to be recursive
      HistoryController: Use a programatically created context menu
      WebHistoryView: Also use the tree context menu
      HistoryController: Add "Open Files" menu item
      CommitController: Reject merges
      PBGitRepository: Clean up the readFromURL: method
      CommitController: Don't turn of off automatic rearranging
      Site: smush.it images
      Also set blobMode / blobSha for unstaged changes.
      PBChangedFile: Add assert to make sure we're not doing something stupid
      IndexController: re-add ellipsis to "Discard Changes" menu item
      DiffHighlighter: Remove weird end line
      HistoryView: Add "SHA" Column and make it hidden by default
      Update releasenotes, as autorefresh won't make it into 0.7
      Add a few more release points
      Add a link to the user survey

Steven Michalske (1):
      HistoryView: Change the way the HEAD is displayed

Stonewall Ballard (1):
      Add preferences for opening things at launch.

dbr (1):
      When selecting a folder in tree-view, display the path rather than the <PBGitTree: 0x...> object.

The shortstat has this to say:

 84 files changed, 5474 insertions(+), 1470 deletions(-)

Introducing a new key to Info.plist
First of you’ll need an additional key in your Info.plist where your custom version-string will be stored. I used “CFBundleGitVersion” and set its content to “GIT_VERSION”. You can simply do that in XCode.

The build-script
You’ll still need a build-script, like I described before. A really simple one would be:
VERSION=$(cd $PROJECT_DIR; git describe)
echo -n "#define GIT_VERSION $VERSION" > $PROJECT_TEMP_DIR/revision
touch Info.plistIf that doesn’t work you might need to include some PATH exports above, but I wanted to keep this example to the relevant parts.

Info.plist preprocessing
Now you can preprocess the Info.plist when building your app, using the revision-file as a header. This means that your GIT_VERSION string will be replaced. Edit your Build-Settings like this:
Using the string in the About-window
So, now your Info.plist contains a meaningful string. You want that to be displayed to the user when he opens the “About” window, but you don’t want to write your own window. First you have to write an IBAction in some controller that’s in your MainMenu.xib. Then you’ll have to reconnect the About-button to that action from your controller, which should look like this:

- (IBAction)showAboutPanel:(id)sender
{
	NSString *gitversion = [[[NSBundle mainBundle] infoDictionary]
		objectForKey:@"CFBundleGitVersion"];
	NSMutableDictionary *dict = nil;
	if (gitversion)
		dict = [[NSMutableDictionary alloc] initWithObjectsAndKeys:
			gitversion, @"Version", nil];

	[NSApp orderFrontStandardAboutPanelWithOptions:dict];
}

So, if gitversion is set then the default Version-string is overwritten with it when calling the about-panel, while for Mac-OS the extra-key in your Info.plist is completely meaningless and to differentiate between version you can still use a simple integer. If that was to hard to follow just have a look at the commit in the GitX-repo.

So I fired up git and started hacking on the genkernel-code and now have a system which does suspend-to-disk and dmraid. Having said that, I must stress that you should really know what you’re doing if you’re trying to use this. You could potentially shoot yourself in the foot if for some reason a hibernated image gets loaded after your harddrives have already been mounted. I try to avoid that in my patch by calling suspend_resume immediately after dmraid has been called (and only there). Improvements or constructive flames would be highly appreciated.

If you want to have something similar with Xcode you can use the “New Run Script Build Phase” to add a simple script to your build-process. In the case of GitX, the code looks like this (the original can be found at xcode-git-build-scripts at GitHub):

#!/usr/bin/env ruby

version = `/usr/bin/env git describe`.chomp

info_file = File.join(ENV['BUILT_PRODUCTS_DIR'], ENV['INFOPLIST_PATH'])
info = File.open(info_file, "r").read

version_re = /([t ]+<key>CFBundleVersion</key>n[t ]+<string>).*?(</string>)/
info =~ version_re
bundle_version_string = $1 + version + $2

info.gsub!(version_re, bundle_version_string)
File.open(info_file, "w") { |file| file.write(info) }
puts "Set version string to '#{version}'"

Needless to say that this script is not very error-resistant, but since ruby is included with OSX and people compiling GitX usually have git installed, it should work in most cases.
Update
I just discovered that the CFBundVersion is supposed to be a monotically increasing integer, separated only by periods. This is required by MacOS and things like Sparkle. The string “git describe” returns doesn’t match these criteria, obviously. So, if you encounter problems, you should fall back to using the format of x.y.z.<commits> where x.y.z is your major release number and <commits> is the number of commits since mentioned tag.

Fortunately there is an easy solution: In git there is contrib/difftool, which makes it easy to display git diffs side-by-side with a viewer of your choice. Of course that meant vimdiff for me. To see all the lines of a file (and not just the changed + a little context) I call git-difftool like this:
git-difftool --tool=vimdiff -U99999Now you can alias that command and use the normal rev-parse arguments. As you can see on the screenshot you can easily distinguish between removed lines, added lines and changed lines. For changed lines the part that was changed is highlighted.

# Set a nice git-prompt (calls git_status())
git_prompt_info() {
  local git_dir ref br;
  git_dir=$(git rev-parse --git-dir 2> /dev/null) || return
  ref=$(git symbolic-ref HEAD 2> /dev/null) || return
  branch_prompt=${ref#refs/heads/}
  if [ -n "$branch_prompt" ]; then
    status_icon=$(git_status)
    echo "$status_icon%{$fg[yellow]%} [$branch_prompt]"
  fi
}
# Show character if index and/or work-tree are dirty
git_status() {
  my_status=$(git status)

  if [[ "$my_status" == *"Changes to be committed"* ]]; then
    output="%{$fg[green]%}+"
  fi

  if [[ "$my_status" == *"Changed but not updated"* ]]; then
    output="$output%{$fg[red]%}*"
  fi

  echo $output
}

Now all you’ve gotta do is call $(git_prompt_info) somewhere in your RPS1.

(A live version with more than one repo can be seen here.)
So far this badge works with Firefox, Safari 3.x and Opera. I haven’t had the resources or motivation to make it work on IE though.
This has been my first foray into the world of JavaScript and DOM, and the first time I really wrote a CSS from scratch, so expect things to be buggy and the code to look slightly amateurish. The script uses JavaScript-libs, which I packed into one big file. jQuery is used to get the data from the Github API, Datejs for parsing the timestamp and an MD5-lib for requesting the gravatars.
If you want to use it on your website you should just download everything from Github and put it on your webspace. The README shows you how to embed it into your webpage (I made sure that the CSS-elements don’t clash with your existing stylesheets).
If you want to contribute to it you’re welcome to (the easiest way is forking the repo at Github), but please don’t try to make it into a monster-app which does much more than it was intended to do.
Thanks go out to DrNic for contributing and also for his Github-badges project for the good code-examples.
(By the way, Github asked for a JavaScript-version in this blog-post, so here it is. I hope they’re not mad at me for stealing the two tiny logos. ;)
Update: I notified defunkt of GitHub and what do you know, I got featured on their blog (entry here). Awesome. I hope I can put some further touches into the project in the next few days.

setopt prompt_subst
autoload -U colors
colors
function __prompt_git()
{
        local git_dir ref br top;
        git_dir=$(git rev-parse --git-dir 2> /dev/null) || return
        ref=$(git symbolic-ref HEAD 2> /dev/null) || return
        br=${ref#refs/heads/}
        top=$(cat $git_dir/patches/$br/current 2>/dev/null) \
                  && top="/$top"
                  echo "[$br$top]"
}
export PS1='[%?]%{$fg[green]%}%n%{$reset_color%}@%m:%~\$ '
export RPS1='%{$fg[yellow]%}$(__prompt_git) %{$reset_color%}%*'
if [[ "$USER" == "root" ]] ; then
        export PS1='[%?]%{$fg[red]%}%n%{$reset_color%}@%m:%~# '
fi

(RPS1 is the right side of the prompt)
This colors your username green and red if you’re root (really helpful). I’ve picked up the habit of giving remote hosts different colors for the username so that when I have many terminals open I can identify the corresponding host not only by name but also by color. The number in front of the username is the return-code of the command just executed.

The title of this post (and the screenshot) already mentioned the second topic. Cygwin. I heard about it before but always dismissed it as a poor attempt to bring something into an operating system in a strange and crippled way just because some people are too scared to switch to a unix system. Well, being at home right now (and using Windows XP here because I am too lazy to switch this old machine and also play the occasional game in my free time ;) made me try cygwin, and I have to say I am impressed. I don’t use it extensively, to be honest I only use it to be able to ssh/scp without using gui-software like PuTTY/WinSCP, to use git without a gui and to have a decent zsh with screen in it. Oh yeah, and vim. Basically all the little life-savers you have with linux (tar, grep, less, sed, man). Just being able to download a tarball (like git or stow) and compiling/installing it like on any unix is quite convenient too. And that works fine with cygwin. You can also access you normal windows-drives and it has a tool (cygstart) to open files with the associated programes (like “open” in Mac OS). Last but not least you can even run an ssh-server, which seems weird at first, but comes in handy when all you want to do is shutdown you windows-box remotely ;). So if you don’t like the rxvt you can always use putty to ssh to localhost (yeah, I don’t do that neither).

Then there are feeds. You can watch projects, which means that your feed includes any commits/comments on the watched projects. It goes without saying that this can be quickly overwhelming for active projects. Comments can be made on specific lines in a commit (or on the whole commit), which is a great feature (think of it as the equivalent to patches being discussed line-by-line in mailing-lists). I still prefer mails though ;)
The syntax-highlighting looks pretty good. I’ve already mentioned the very pale interface (as in low-contrast) and it still has not changed. But I think that most people really browse the commit history in their local clones anyway.
Each project has an attached Wiki too, so you can add a few pages (or a lot if you wish).
To conclude I can say that GitHub is a great service, since it has a free plan for public projects. I would not need it for my personal projects, but to run a or contribute to a open-source project it’s perfect. The amount you use its features is up to you. If you already have a Wiki, already have an active mailing-list and discuss patches there too then you can just use GitHub as the central source code repository (plus the forks of course). The real work is done on your local repository with git anyway, but y’already knew that I guess ;)