/tracker

Simple GIT patch review tracker

Primary LanguageJavaScript

GIT Tracker

Installation and usage

  • $ gem install tracker-client

  • $ git clone git://github.com/mifo/tracker.git

  • $ cd tracker

  • $ bundle

  • $ rackup config.ru

This will start the web server on port 9292. Now navigate to http://localhost:9292/patches. The page appears to be empty, because you don't have any patches recorded yet.

Now choose a GIT repo from where you want to record your patches. That repo should have a designated branch with your work checked out (it should be the current working branch).

Now you can record the patches (the -d part is optional, when omitted, current working directory is used instead:

  • $ tracker record [-d PATH_TO_YOUR_GIT_REPO]

Then you may refresh the blank web page and you should see something like this in the timeline:

img1

And you may view details about the patchset you sent here:

img1

If you want to also upload all your patches to server after recording, just add -u option after record command.

Good. You have just recorded your patches, so now you don't loose track of them. Go ahead, send your patches to the mailing list, and find someone who will review your patches.

Also you can use the shell script git-tracker-send that will record the patches and call 'git send-email' command.

In addition to recording your patches, you can use -u option and tracker client will upload your patches into tracker application. The users can the download and apply your patches by simply typing:

$ tracker apply COMMIT_HASH

You can also download whole set and apply the patches using:

$ tracker download SET_ID -b your_review_branch

If the person is happy about what you did, and wants to give you an ACK, then he can do it by:

  • $ tracker ack [-d PATH_TO_REVIEWER_GIT_REPO]

NOTE: He must have the branch with applied patches set as 'current', so tracker can read the history and get the patch hashes.

Now if you refresh the web page, you will see that all patches are marked by 'ACK' and are green:

img2

That means, they are good to go. Lets push them. Before push, you may indicate, that you're going to push them:

  • $ tracker push [-d PATH_TO_YOUR_REPO]

The patches will get the 'PUSH' stamp and tracker job is done here. You may push your patches to remote GIT repository now :-)

Patchset revisions:

Tracker now support 'obsoleting' patch sets when they are 're-sent' (ie. new revision of the same patch set is sent to list). To obsolete particular patch set, you first need to log into UI and obtain his 'id' (#ID), then you record your new patchset in this way:

  • $ tracker record -o ID

The new patchset will replace the old patchset and the version of 'rev' will be bumped by 1.

Client configuration

By default the tracker command line client will try to connect to tracker server running on localhost using 'default' credentials. You might need to change this by:

$ wget https://raw.github.com/mifo/tracker/master/config/trackerrc.example -O ~/.trackerrc

Then edit the ~/.trackerrc file and provide valid credentials / URL.

TODO

See: Issues

FAQ

  • Q: Why not Gerrit/etc ?

Because Gerrit is 'too much'. We don't want to change the way we do patch reviews (using mailing list), we just want to keep 'track' about our patches, so they don't get lost in list after a while.

  • Q: Will Tracker watch my mailing list

No.

API structure

  • GET /set [JSON, HTML] - Return all 'sets' (patch sets) that are recorded.

  • GET /set/:id [JSON, HTML] - Return the 'set' (patch set) identified by :id.

  • POST /set [JSON] - Create new patchset. The request body contain JSON serialization of the patchset.

  • GET /set/:id/destroy - Destroy given patchset. (The revision is changed to -1)

  • GET /patch/:id [JSON, HTML] - Get details about the patch. The :id is the patch commit hash.

  • GET /patch/:id/download - Get content (diff) of the patch if uploaded. The :id is the patch commit hash.

  • PUT /patch/:id/body - Attach the patch body (diff) to this patch. The request body should contain the raw diff (git format-patch output)

  • POST /patch/:id/status - Update status of the patch identified by :id. The 'status' parameter indicated the target status (ack, nack, push, note).

Designed workflow:

    1. Person A: $ git checkout awesome_pathes
    1. Person A: $ git rebase -i master
    1. Person A: $ git format-patch -o /tmp/patches master
    1. Person A: $ git send-email --thread /tmp/patches
    1. Person A: $ tracker record -> (Sends all patches to the 'tracker' application, they appear as 'NEW'. Each patch is 'identified' by its commit HASH)
    1. Person B: Review patches on the mailing list, ie. creates a new branch in his local GIT and applies patches, then Person runs on his local machine in the GIT repo on local branch he created:

$ tracker ack ('tracker' will set all patch hashes in application to ACK)

$ tracker nack ('tracker' will set all patch hashes in application to NACK)

$ tracker [ack|nack] hash ('tracker' will ACK/NACK just specified hash in application)

    1. Person A: $ git checkout awesome_patches
    1. Person A: $ tracker status

This should print status of review for each commit, like:

  [ ACK ] 2ad28717 Commit Message 1
  [ NCK ] 2fb0cbb0 Commit Message 2
  [ NEW ] 34fb7b78 Commit Message 3
    1. Person A: $ git push -> (Pushes ACK'ed patches).
    1. Person A: $ tracker pushed [patches] -> (Notifies tracker that the patches were pushed, ie. set status of patches to PUSH)
    1. Person A: Buy beer to Person B ;-)