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

The ruby script I wrote does basically this, but it grabs the rev-list from fisheye (I should change that; this is a lot simpler and I'm not sure why I didn't think of it). It takes multiple issues and sorts them into the correct chronological order. WE SHOULD COLLAB

Great idea, my only suggestion is to make it a git command fo realz: http://blog.thehippo.de/2012/03/tools-and-software/how-to-create-a-custom-git-command-extension/

Also, anyone played with https://github.com/visionmedia/git-extras ?

Revisiting this... as I'm going through another massive cherry pick from master to prod. What do you guys think of this general algorithm I wrote up:

Algorithm for perfect JIRA issue cherry picker

• Retrive the commit list with a variety of grep regex to help
  pattern match lazy typers: /\s*CUR-1234/i /^1234/ == CUR project

• Attempt to detect missing JIRA text in a diff. If a commit in
  the middle of the jira commits does not contain any issue tag,
  print out the commit description and ask the user:
  "Is this yours? Did you forget to write in the JIRA issue?"

  • If Yes, add it to the list of commits

• Check the file list in the jira diffs

• Check through each file in prod, looking to see if the earliest
  commit in this jira issue is later than the latest commit in
  each file. (IE: are we attempting to skip a commit in prod
  that will result in an auto-resolve conflict

    Automatic cherry-pick failed.  After resolving the conflicts,
    mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
    and commit the result with: 
  
    git commit -c fd2174dc87ff1a14ac4b02bd99ecf1d1304a0659
  

• show the skipped commits, and then ask the user if they want
  to cherry pick those first

• show the commits and short description in chrono order for
  the jira issue

• ask the user if they want to cherry pick this list

• cherry pick each individual commit, printing out each one

  • Find a better way to cherry-pick without the auto merge
    freaking out over whitespace inconsistencies

• if one fails, ask if:

  • you want to roll it back?
  • show a list of files & conflicts?

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.