The contents of the releases

While extracting information from Git, one of the natural things to do is to generate release notes. To generate a release note, you need all the valid information from the repository between this release and the previous release.

We can utilize some of the methods we have used earlier to generate the data we want.

How to do it...

We start by listing the commits between two tags, v2.3.1.201302201838-r and v3.0.0.201305080800-m7, and then we build on that information:

  1. By using git log with v3.0.0.201305080800-m7.. v3.0.0.201305080800-m7, we will get the commits between the tags:
    $ git log --oneline v2.3.1.201302201838-r..v3.0.0.201305080800-m7
    00108d0 JGit v3.0.0.201305080800-m7
    e27993f Add missing @since tags
    d7cc6eb Move org.eclipse.jgit.pgm's resource bundle to internal package
    75e1bdb Merge "URIish: Allow multiple slashes in paths"
    b032623 Remove unused repository field from RevWalk
    a626f9f Merge "Require a DiffConfig when creating a FollowFilter"
    
  2. As we have a lot of commits between these two tags, let's count them using wc -l:
    $ git log --oneline v2.3.1.201302201838-r..v3.0.0.201305080800-m7 | wc -l
        211
    
  3. There are 211 commits between the tags. Now, we will show the most modified files between the releases:
    $ git log  v2.3.1.201302201838-r..v3.0.0.201305080800-m7  --format=format: --name-only | sed '/^$/d'  | sort | uniq -c | sort -r | head -10
         11 org.eclipse.jgit/src/org/eclipse/jgit/internal/st
         10 org.eclipse.jgit/src/org/eclipse/jgit/internal/sto
         10 org.eclipse.jgit.pgm/resources/org/eclipse/jgit/p
          9 org.eclipse.jgit.test/META-INF/MANIFEST.MF
          8 pom.xml
          8 org.eclipse.jgit/src/org/eclipse/jgit/storage/pac
          8 org.eclipse.jgit/src/org/eclipse/jgit/internal/sto
          8 org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/CLI
          7 org.eclipse.jgit/src/org/eclipse/jgit/storage/dfs/D
          7 org.eclipse.jgit/src/org/eclipse/jgit/storage/dfs/D
    
  4. This information is valid as we now have an overview of where the majority of the changes are. Then, we can find the commit that refers to bugs so we can list the bug IDs:
    $ git log --format=format:%h --regexp-ignore-case  --extended-regexp --grep="bug: [0-9]{6}"  v2.3.1.201302201838-r..v3.0.0.201305080800-m7 | xargs -n1 git log -1 | grep --ignore-case -E "commit [0-9a-f]{40}|bug:"
    commit e8f720335f86198d4dc99af10ffb6f52e40ba06f
        Bug: 406722
    commit f448d62d29acc996a97ffbbdec955d14fde5c254
        Bug: 388095
    commit 68b378a4b5e08b80c35e6ad91df25b1034c379a3
        Bug: 388095
    commit 8bd1e86bb74da17f18272a7f2e8b6857c800a2cc
        Bug: 405558	
    commit 37f0e324b5e82f55371ef8adc195d35f7a196c58
        Bug: 406722
    commit 1080cc5a0d67012c0ef08d9468fbbc9d90b0c238
        Bug: 403697
    commit 7a42b7fb95ecd2c132b2588e5ede0f1251772b30
        Bug: 403282
    commit 78fca8a099bd2efc88eb44a0b491dd8aecc222b0
        Bug: 405672
    commit 4c638be79fde7c34ca0fcaad13d7c4f1d9c5ddd2
        Bug: 405672
    
  5. So, what we have here is a nice list of the bugs being fixed and their corresponding commit hashes.

How it works...

We are using some bash tools to get this list of fixed bugs. I will briefly explain what they are doing in this section:

  • The xargs -n1 git log -1 part will execute git log -1 on each commit coming from the first git log command, git log --format=format:%h --regexp-ignore-case --extended-regexp --grep="bug: [0-9]{6}" v2.3.1.201302201838-r..v3.0.0.201305080800-m7.
  • The grep --ignore-case -E "commit [0-9a-f]{40}|bug:" grep will ignore the case in the regular expression and -E will enable an extended regular expression. You might see that a lot of these options for the tool grep are the same options we have for git log. The regular expression is matching commit and 40 characters with the [0-9a-f] range or bug:. The | character means or. Remember we are in the out from git log -1.

All of this information we have extracted is the basis for a good, solid release note, with information on what has changed from one release to another.

The next natural step would be to look into the bug tracking system and also list the titles for each error being fixed in the commits. However, that is not something we will go through here as it all depends on the system you are using.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset