gistfile1.tcl

#!/usr/bin/tclsh8.5
#
# Usage: unmerged branch1 branch2

proc getlog branch {
    lrange [split [exec git log $branch --oneline] "\n"] 0 100
}

proc diff {title c1 c2} {
    puts "\n$title"
    foreach commit1 $c1 {
        set found 0
        set sha [lindex [split $commit1] 0]
        set msg [join [lrange [split $commit1] 1 end]]
        foreach commit2 $c2 {
            set msg2 [join [lrange [split $commit2] 1 end]]
            if {$msg eq $msg2} {
                set found 1
                break
            }
        }
        if {!$found} {
            puts "$commit1"
        }
    }
}

if {[llength $::argv] != 2} {
    puts stderr "Usage: unmerged branch1 branch2"
    exit 1
}
set branch1 [lindex $::argv 0]
set branch2 [lindex $::argv 1]

set c1 [getlog $branch1]
set c2 [getlog $branch2]
diff "Only in $branch1" [lrange $c1 0 50] $c2
diff "Only in $branch2" [lrange $c2 0 50] $c1

Example:

$ unmerged 2.6 unstable

Only in 2.6
7c1cec2 Redis cluster stuff removed from 2.6 redis.conf file.
518e720 Fixed typo in 2.6 release notes.
f597910 Merge remote-tracking branch 'origin/2.6' into 2.6
749817b Version bumped to 2.5.2
7551f2a Version is now 2.5.1, first unstable release of Redis 2.6
571e257 Redis 2.6 branch obtained from unstable removing all the cluster related code.

Only in unstable
7964242 Merge pull request #378 from quiver/unstable

Excellent idea! I took a go at using git's cherry command, which compares changesets rather than just the SHA1 (though conceivably there could be situations in which that's undesirable, it seems like the right "default behavior").

Also figured the default case if I only give one branch is to compare against HEAD, and if I omit both it will check HEAD vs master.

#!/bin/bash

BRANCH1=${1:-master}
BRANCH2=${2:-HEAD}

echo; echo "Only in $BRANCH1"
git cherry -v $BRANCH2 $BRANCH1

echo; echo "Only in $BRANCH2"
git cherry -v $BRANCH1 $BRANCH2

Does the following generate a different behavior?

#!/bin/bash

echo "\nOnly in $1"
git log --oneline $1..$2

echo "\nOnly in $2"
git log --oneline $2..$1

Both the proposed solutions will generate a different output compared to the script:

@agnoster solution does not recognize that a commit, if modified for merging issues, is the same commit.
@mauriziodemagnis solution will just show every commit with a different SHA that is not in the second branch, and is thus useless for the purpose ;)

Salvatore

@antirez Ah! Good point :-) Also I didn't read your version carefully - are you just comparing commit messages? That probably works okay most of the time, but could be dangerous for people who have others on the team who write commits like "fixed some bugs". Sadly, this still happens. :-(

@agnoster: yes indeed I'm simply comparing commit messages, so it can surely miss commits. It's ok in a small controlled environment but I agree it can be dangerous, unless the team agrees about writing log commit messages. Btw since the comparison is performed only against the latest 100 commits the chance of a problem is not big.

@antirez Actually it could make a good motivation to explain to people the importance of writing meaningful commit messages! Anyway, thanks for this gem, it's an excellent idea, I'll try using my version and see if it's more of a help or hindrance to see each distinct changeset, maybe switch to yours if it annoys me ;-)

I arrived here while looking to solve a slightly different problem: I'd like to see the branches (and commits therein) that aren't merged with master (or another branch that I specify). I found this 'git-unmerged' script very useful for solving that: http://mutuallyhuman.com/blog/2009/07/02/finding-unmerged-commits-with-git-unmerged

Posting here in case others find themselves in a similar situation.