workflow description for an scm

July 25, 2007

I setup the bits to make git the scm format for yum-devel. setting it up wasn’t all that difficult, actually. The hard part now is adapting my work flow to work with this.

Here are the set of things I need to do w/an scm:

Thing 1:

check out HEAD from my scm. modify files locally. check in changes and have them be available to all other developers. Dealing with conflicts and merges along the way.

I can do this now with git as it’s been setup. (git pull, git commit -a, git push)

Thing 2:

as we move to a new development cycle in yum I need to be able to take the latest HEAD, make a branch of it to become yum-3.2.X (for example) and diverge from there. So that I can commit new dangerous stuff to HEAD and only put backports and fixes into the yum-3.2.X branch. I do this by making a new sandbox dir for my 3.2.X branch so I can cd into that dir, fire up an editor and work w/o wondering what branch I’m in.

I can _mostly_ do this now in git. the pushing and pulling from branch to branch and getting the changes to the non-HEAD branch is excruciatingly arcane set of commands, but I think it works, sorta.

Thing 3:

From any given branch (HEAD or one of the maintenance branches) I need to create an arbitrary tag which specifies the files in a specific version of yum: re: yum-3-2-3 on the yum-3-2-X branch. or yum-5-0-0 on the yum-HEAD branch. Then with those tags I need to be able to check out a tag like this from my build script, make a tarball and build from there.

I can list the tags, I’m not _really_ sure how to make the tags and if the tags are per-branch or are independent of the branch.

Thing 4:

I want to generate a changelog from commit comments in just this branch, nothing else.

No clue if the log command in git obeys what branch you’re currently on or not. This was one of the things in cvs that always felt odd.

So that is ALL of the features that I require out of an SCM and that is how I do things. Any suggestions on what I should be doing to make the above more obvious to me and to any future contributor?

What I’ve noticed so far is that every time I want to do anything in git I have to be remarkably verbose about what I want. So if I’ve made a new clone and I set the branch to be a local track of some branch remotely, I expect that when I make changes and want to push them that I don’t need to tell it the branch I want to put them in, again. Since it knows where the branch I want to use is when I run ‘git pull’ I would expect it could use that same path for ‘git push’. Tonight I discovered that it can – but only if the local copy of the branch and the remote copy of the branch have the same name. It doesn’t just keep track of it on its own. Even though it is already in the metadata. I’ve played with git enough now to know that I can probably force it to work but it won’t feel all that sane for a while.

Toshio and Warren helped me figure out how to do something similar to that in bzr_ng tonight. The interface to bzr is far and away less painful than git’s. But since a lot of things in fedora sure seem like they’re leaning in the direction of git (most importantly to me fedora-admin scm) I’m trying to learn git as much as possible but as I said today on my email about the yum git repositories:

I don’t work on yum to be good at using git. Nor did I work on yum to be good at using cvs or svn or bzr or hg. They are just means to an end. If I find I’m spending a lot of time screwing around fighting with git (I’m going to exclude this week b/c that’s ALL I’ve done this week) we may see this distributed-scm-experiment come to a shrieking and sudden halt.

3 Responses to “workflow description for an scm”


  1. Hi Seth

    I have also pull out a lot of hair to get used to using
    git🙂

    I have found this guide very useful.
    http://wiki.sourcemage.org/Git_Guide

    Here is a example for making a local branch tracking a remote branch.
    cd yum-utils ( the project dir created by git clone)

    # create a local yum-utils-1_0_X branch tracking the remote origin/yum-utils-1_0_X branch
    git branch –track yum-utils-1_0_X origin/yum-utils-1_0_X

    # checkout the local yum-utils-1_0_X branch
    git checkout yum-utils-1_0_X

    git pull, git log, git commit -a, git pull etc. are all working on the current branch (local & remote)

  2. Jeremy Katz Says:

    The key with the tracking branches and pushing is having the named the same as the remote branch. Which is just a bug, but an annoying one all the same.

  3. Jeremy Katz Says:

    And looking at upstream git, it looks like tracking branches have been fixed to act a bit more like would be expected with an arbitrarily named local branch for git 1.5.3 (currently at -rc3). Tracking branches have also been made the default behavior.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: