Blag

He's not dead, he's resting

Exherbo Development Workflow

Update: also see Exherbo Development Workflow, Version 2.

In answer to what appears to be becoming a frequently asked question in #exherbo, my development workflow (and by extension, the one true workflow, any deviation from which is clearly heresy) is as follows:

For any repository I consider interesting, I have a local copy (but not a clone, because git clone is Satan’s work) in my home directory.

For Paludis, every repository it sees has location under /var somewhere. Paludis is never pointed at a repository that is modified by anything other than itself.

For syncing, any repository I consider interesting is synced using sync = git+file:///home/users/ciaranm/repos/blah, with sync_options = --reset (as previously described). Others are synced as normal.

Before syncing normally, I pull all of the interesting repositories I have checked out in my home directory, so that Paludis ends up with everything up to date. The shell one-liner to do this is in my history, so it’s no additional work thanks to the wonder that is reverse-i-search.

On those rare occasions when I have to do some work on Exherbo that I can’t either just yell about until someone fixes it for me or force to be fixed by making Paludis reject it, I work as follows:

  • Changes are made and committed in my home directory copy of the repository.
  • Paludis is synced, picking up those changes.
  • Testing is done.
  • More changes are made and committed, since things never work as expected the first time.
  • Paludis is synced, picking up those changes.
  • And so on.
  • When things finally work, git rebase -i is used to turn all my messy work-in-progress commits into something suitable for pushing. Given that other people are often working on the repositories in question, this also rebases my changes against current master.
  • Things are pushed.
  • When syncing again, the --reset ensures that Paludis ends up with the history-rewritten result, not some horrible automatic merge of the end result and previous works in progress.

Fortunately, Git is easily powerful enough to handle this kind of thing, meaning Exherbo development workflows are designed around what works best, not around what is possible.

On a related note, I am still strongly considering making --reset the default one of these days. Anyone using paludis --sync on a repository they themselves modify should quickly justify their iniquity or risk being horribly surprised when the default changes.

Advertisements

8 responses to “Exherbo Development Workflow

  1. Ewoud Kohl van Wijngaarden November 4, 2009 at 4:46 pm

    Why’s git clone satan’s work?

    • Ciaran McCreesh November 4, 2009 at 5:10 pm

      Because it tries to be too clever and set up too many things automatically. Case in point: it creates a remote named ‘origin’.

  2. Erik Li November 12, 2009 at 3:26 pm

    I’m new to git and was just wondering: what is the alternative to git-clone? Do you just git-init a new folder and git-pull the repository? The problem with this is that then you can’t just type “git pull” without specifying an upstream repository.

    • Ciaran McCreesh November 12, 2009 at 3:31 pm

      git init, git remote add, git fetch. I consider git pull to be harmful because it tries to do too much. It’s much cleaner to use fetch, and then either merge or rebase by hand as you see fit after having reviewed what’s changed.

  3. Pingback: Exheres way | MatrixPad

  4. Pingback: Exherbo Development Workflow, Version 2 « Ciaran McCreesh’s Blag

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