Search code examples
gitgit-log

How do I display the intersection of commits between two branches in git log?


I have a main branch as the root. Depending on the minor version, I create branches in the dev family, such as dev/2.3, dev/2.4, dev/2.5, dev/2.6. Currently, dev/2.6 is the active branch for development.

For a specific task, I branch off from dev/2.6 and work, for example, in tasks/task1. I make commits and push them to the remote tasks/task1 branch. Afterward, I create a pull request from tasks/task1 to dev/2.6. Then, after some time, I create a pull request from dev/2.6 to main.

My question is whether it's possible, after merging dev/2.6 into main via a pull request, to use the

git log 

command to find the intersection of commits between dev/2.6 and main?

For instance, I tried

git --no-pager log --oneline main..dev/2.6,

but this command only shows the differences in commits. What I need is to log all the commits made in dev/2.6 that are present in main but not in dev/2.4, dev/2.5, and so on. Is there a git log syntax for displaying the output of a list of commits exist only in dev/2.6 and main??

Thank you advance


Solution

  • You can't exactly get that because if you've merged them together then everything in dev/2.6 is in master ( but not everything in master is in dev/2.6)

    The usual thing I can think of that is close to what you want is 'what did dev/2.6 add since our last release. If you had tagged that release with a version tag this would be even easier.

    Here are some ways I can think of that try to get to what you wanted:

    In short: git log main dev/2.6
    but likely better done with
    git log --graph --abbrev-commit --decorate --date=short main dev/2.6
    or whatever log mechanism you prefer.

    This says to log both main and dev/2.6 together so you will see where they diverge and where they merge together and if they diverge after that.

    A better thing I would think of using is git shortlog dev/2.6 ^dev/2.5 or git shortlog dev/2.6 ^origin/master or replace origin/master with the fork point where dev/2.6 broke off from. Which would show you whats on dev/2.6 that wasn't on dev/2.5 or master respectively.

    This really breaks down if you merge master into those branches multiple times or those branches were merged multiple times back to master. Which is why I take tags when using a flow like this, when I merge dev/2.6 back to master I would tag that commit as v2.6.1 and if I merged again v2.6.2 etc. in this way I can do git short-logs between the current state or tag and the prior tag to see what was added.