===== git log ====
commit 98eb9c95fb753d012b78e9d32fdb4972752e02cd
Author: Hari Gowtham <hgowtham@redhat.com>
Date:   Tue Apr 7 18:52:38 2020 +0530

    doc: Added release notes for 5.13
    
    Change-Id: Id168b675f8afae2ba2e5c8ac5b431aa14c832b54
    fixes: #1147
    Signed-off-by: Hari Gowtham <hgowtham@redhat.com>

commit 111c5f382f2ba6ac36b9ff702878214eb4d7381a
Author: Xavi Hernandez <xhernandez@redhat.com>
Date:   Sun Mar 8 18:36:45 2020 +0100

    open-behind: fix missing fd reference
    
    Open behind was not keeping any reference on fd's pending to be
    opened. This makes it possible that a concurrent close and en entry
    fop (unlink, rename, ...) caused destruction of the fd while it
    was still being used.
    
    Change-Id: Ie9e992902cf2cd7be4af1f8b4e57af9bd6afd8e9
    Fixes: #1028
    Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>

commit bd370c3d537a3d5a11387e38c1a2a3bd6e3a275d
Author: Krutika Dhananjay <kdhananj@redhat.com>
Date:   Mon Mar 23 11:47:10 2020 +0530

    features/shard: Fix crash during shards cleanup in error cases
    
    A crash is seen during a reattempt to clean up shards in background
    upon remount. And this happens even on remount (which means a remount
    is no workaround for the crash).
    
    In such a situation, the in-memory base inode object will not be
    existent (new process, non-existent base shard).
    So local->resolver_base_inode will be NULL.
    
    In the event of an error (in this case, of space running out), the
    process would crash at the time of logging the error in the following line -
    
            gf_msg(this->name, GF_LOG_ERROR, local->op_errno, SHARD_MSG_FOP_FAILED,
                   "failed to delete shards of %s",
                   uuid_utoa(local->resolver_base_inode->gfid));
    
    Fixed that by using local->base_gfid as the source of gfid when
    local->resolver_base_inode is NULL.
    

More commit messages for this ChangeLog can be found at
https://forge.gluster.org/glusterfs-core/glusterfs/commits/v5.13
