Jira cherry-picker galore?

gistfile1.txt

#!/bin/sh

JIRA_ISSUE=$1
BRANCH=$2

if [ "$BRANCH" = "" ]; then
  BRANCH="master"
fi

echo "Commits in branch $BRANCH for issue #$JIRA_ISSUE"
echo "------------------------------------------------"
echo ""

git log --grep="^$JIRA_ISSUE " --reverse $BRANCH

echo "------------------------------------------------"
echo "Would you like to cherry-pick the above commits "
echo "into your current branch? (yes/no)              "
read YESNO

if [ "$YESNO" = "yes" ]; then
  echo ""
  echo ""
  echo ""
  COMMIT_LIST=`git rev-list --grep="^$JIRA_ISSUE " --reverse $BRANCH`

  ### 
  # Replay commits one by one, rather than piping full list to git-cherry-pick,
  # making merge conflicts slightly less confusing.
  ### 
  for commit in $COMMIT_LIST; do
    echo "$commit"
  done
else
  echo "Aborting..."
fi

This sounds pretty solid, as you described.

One rant I'll drop in here: we pick too many cherries. We've developed a cherry-pick always, merge never mentality when transferring changes from master to production. As pointed in numerous references, cherry-picking breaks tracking commits by duplicating the history of that change, which makes it harder and harder to merge branches back together. The problem, as it was in surround, commiting a patch across branches (which is all a cherry-pick is) is always far easier than merging.

I don't know what the best fix is yet. I proposed to the API team of going to a pull request model of tracking and integrating features. I'd love to hear proposals.

Regardless, this is a fine tool for making the cherry picks we do need to make much easier.

+1 Cal, +1 Wade.

I agree with the pull request/merge idea. I've mentioned that a couple times to the web dev team as well. It would also help out for getting another set of eyes on things as well.

If webdev followed this, it would go something like:

• Constrain each feature to it's own branch
• Merge into master for dev/alpha testing
• Merge into production branch for websrc testing
• Install live from the same branch that websrc was tested on (in webdev's case production). That way when testing we at least know that websrc and live use identical codebases.

Using one branch for websrc/prod would still require something like the deploy dog though (granted that's another discussion entirely). This would at least avoid the cherry-picks on bigger change sets, but you could still use the cherry-pick method for smaller changes like bugs.

Honestly, I think our team at least needs to get better about using feature branches more often regardless.