11

My product is a plugin for IntelliJ. I support several versions of the underlying IntelliJ platform, and release builds of my plugin for each one since their APIs often change between versions. It's just me working on it, so I develop in master and then maintain a branch for each of the other versions. So my repo looks like this:

   1.6.0  1.6.1-eap1
.... a---b---c--- master
      \       \
       d-------e--- idea-2017.1
        \       \
         f-------g--- idea-2016.3
          \       \
          ...     ...  etc etc

a is a stable release, and has been tagged with 1.6.0. c is an EAP (beta) release, and has been tagged with 1.6.1-eap1. This scheme works fine for these two cases.

Occasionally I'd like to create a dev build which doesn't go into a release channel, but that users can download manually and test out if they like. I'd like to produce a dev build for each platform, since dev users could be using any IntelliJ version. The best way I can think of would be to create a branch for the dev build from, say, tag 1.6.0 (commit a), and then corresponding branches from commits d, f and so on which I can merge the dev branch into and create dev builds from.

Assuming I want to write a script to create and maintain these branches, how can I find commits d, f and so on from the tag 1.6.0 to create the dev build branches from?

Colin
  • 1,112
  • 2
  • 7
  • 16
  • Wouldn't you want to use the latest version for each IntelliJ version as the base for your dev branches? I.e. using c, e and g instead of a, d and f. I would think that those contain the latest fixes for each version and were the better base for testing new development. – lucash Jul 15 '17 at 08:59
  • Sure, that is possible, but the problem is the same - given the tag `1.6.1-eap1`, how do I find commits `e`, `g` etc. Basically I'd like to be able to create the branches from any tagged revision, which are guaranteed to have merge commits merging into each version branch. – Colin Jul 16 '17 at 07:30

3 Answers3

3

Here's what I ended up doing:

#!/bin/sh

set -e  # Automatically abort if any simple command fails

die () {
    echo >&2 "$@"
    exit 1
}

[ "$#" -eq 2 ] || die "Usage: $0 <branch name> <tag>"

tag_commit=$(git rev-list --abbrev-commit -n 1 $2)
[ "${tag_commit}" = "" ] && die "No commit found for $2"

child_commit() {
  git log --graph --pretty=format:"%h %p" --decorate -20  --first-parent $1 | grep $2 | cut -c 3-10
}

branch_2017_1=$(child_commit idea-2017.1 $tag_commit)
[ "${branch_2017_1}" = "" ] && die "No commit found for idea-2017.1"

branch_2016_3=$(child_commit idea-2016.3 $branch_2017_1)
[ "${branch_2016_3}" = "" ] && die "No commit found for idea-2016.3"

branch_2016_2=$(child_commit idea-2016.2 $branch_2016_3)
[ "${branch_2016_2}" = "" ] && die "No commit found for idea-2016.2"

branch_2016_1=$(child_commit idea-2016.1 $branch_2016_2)
[ "${branch_2016_1}" = "" ] && die "No commit found for idea-2016.1"

git branch "$1" $tag_commit
git branch "$1-2017.1" $branch_2017_1
git branch "$1-2016.3" $branch_2016_3
git branch "$1-2016.2" $branch_2016_2
git branch "$1-2016.1" $branch_2016_1

Now I'll just update my merging and release preparation scripts to optionally accept a branch series name, and I think I'll be good.

The secret sauce is in the child_commit function, which is cribbed from here.

Colin
  • 1,112
  • 2
  • 7
  • 16
1

For the problem "find in between a ang g earliest commits from idea-2016.3 which was not in idea-2017, and earliest in idea-2017 which was not in master" solution would be to use command:

git log --oneline --source --ancestry-path  master idea-2017 idea-2016.3 --not 1.6.0

output is, in history same to yours:

cf32d9f idea-2017 e
88f264c idea-2016.3 g
5bc9fa1 idea-2017 d
3f460fe idea-2016.3 f
224cac8 master c
67620cd master b

Then find latest line marked with idea-2016.3 and latest one marked with idea-2017, that would be your commits.

Note that the output might be not desirable if there was some blocker issue due to version differences in for example f which was fixed in subsequent f'. So I would still consider explicit tagging.

max630
  • 8,762
  • 3
  • 30
  • 55
  • Thanks, I like this better than my initial version. I'm using awk to get the last commit: `awk '$2 == "idea-2017.1" {commit=1} END{print $commit}'` – Colin Jul 17 '17 at 21:50
0

Probably the easiest way is just to maintain a list of the supported versions/branch names in the shell script?

The reason I'm thinking this is if you add another change: 

1.6.0      eap1 eap2
.... a---b---c---h--- master
      \       \   \
       d-------e---i--- idea-2017.1
        \       \   \
         f-------g---j--- idea-2016.3
          \       \   \
          ...     ...  etc etc

You want that change (h) merged into the head of the branches shown in your diagram, i.e h is merged to e and g. The branch 2017.1 would have been pointing at e which is the right commit to merge onto.

You could do something with walking back to find a common ancestor or something but I think that's needlessly complex and doesn't really buy you anything.

Plus if you just keep a list of branches you can stop supporting old versions relatively easily.

lfn3
  • 1
  • 1
  • So my branch maintenance scripts already do have the branch names hard-coded, and when I support a new version I update them. So far, so good. The problem is that I don't always want to create these dev builds for new functionality - a frequent use case is that a user has a problem that I can't reproduce. Based on stack traces or whatever that they send me, I work up a fix but I can't really test it. In that case, I'd want to make a dev build with the fix that they can test, and I need to base that off the version they're running. – Colin Jul 17 '17 at 00:20