tags:

views:

147

answers:

3

Background: I use an automated build system which takes a git hash as input, as well as the name of the branch on which that hash exists, and builds it. However, the build system uses the hash alone to check out the code and build it -- it simply stores the branch name, as given, in the build DB metadata.

I'm worried about developers accidentally providing the wrong branch name when they kick off a build, causing confusion when people are looking through the build history.

So how can I confirm, before passing along the hash and branch name to the build system, that the given hash does in fact come from the given branch?

A: 

One possible non-solution would be to parse the result of:

$ git reflog show myBranch

and see if your hash is in it.

C:\Prog\Git\tests\rep\main>git reflog show patches
786a190 patches@{0}: rebase finished: refs/heads/patches onto 74630b983db476c323b1d3f6771e57484551240e
8448d0f patches@{1}: master~1: updating HEAD
74630b9 patches@{2}: commit: test2
1e73e36 patches@{3}: branch: Created from master

I keep this as a Community Wiki answer to remember Igor Zevaka and Chris Johnsen's comments:

Would that work after a clone?
Pretty sure your reflog starts after you clone a remote. So if a branch had a commit before the clone, it wouldn't show up in the reflog.

There are also problems with pushes, rebases, fetches (for ‘remote tracking’ branches), and pulls (either merge or rebase type) where only the new tip commit ends up the reflog.
Also reflogs are disabled by default in bare repositories (the most common destination for pushes).
Also, if “cheating” is a problem, it is just a matter of editing a text file to add or delete reflog entries, but it is a bigger ordeal to alter the history graph itself.

VonC
Would that work after a clone? Pretty sure your reflog starts after you clone a remote. So if a branch had a commit before the clone, it wouldn't show up in the reflog.
Igor Zevaka
Right, @Igor Zevaka. There are also problems with pushes and rebases (where only the new tip commit ends up the reflog). Also reflogs are disabled by default in bare repositories (the most common destination for pushes). Also, if “cheating” is a problem, it is just a matter of editing a text file to add or delete reflog entries, but it is a bigger ordeal to alter the history graph itself.
Chris Johnsen
+7  A: 

You can ask git branch directly which branches contain the commit in question:

% git branch -a --contains 4f08c85ad
* master
  remotes/origin/bug_872
  remotes/origin/bug_898
  remotes/origin/master
Dustin
+2  A: 

Hmm, this use of a branch name seems fishy. As in Dustin's answer, there may be multiple branches that contain a commit. Why is any one of those branch names better than another for this purpose?


If you only care about one specific branch, you could compute the “merge base” between the branch and the commit.

In the following diagrams, the commit to build is C, the tip of the claimed branch is T, and the merge base is labeled with M above it.

  • If M equals C equals T, then the the commit to build is the tip of the claimed branch.

                   M
                   ↓
    o--o--o--o--o--x  branch  # x is both C and T
    
  • If M equals C, then the tip of the claimed branch is a descendent of the commit to build.

          M
          ↓
    o--o--C--o--o--T  branch
    
  • If M equals T, then the commit to build is a descendent of the tip of the claimed branch.

          M
          ↓
    o--o--T           branch
           \
            o--o--C
    
  • If M equals something else, then C is a descendent of some ancestor of T.

          M
          ↓
    o--o--o--o--o--T  branch
           \
            o--o--C
    
  • If there is no M, then the commit to build is not related to the claimed branch.

    o--o--o--o--o--T branch
    
    
    o--o--o--o--C
    

You can make this check like this:

#!/bin/sh

# Usage: is-ancestor-of <branch> <commit>

if test $# -ne 2; then
    echo "$0"': invalid arguments'
    exit 128
fi
claimed_branch="$1"
commit="$2"

merge_base="$(git merge-base "$commit" "$claimed_branch")" &&
  test -n "$merge_base" &&
  test "$merge_base" = "$(git rev-parse --verify "$commit")" &&
  exit 0

echo "$commit is not an ancestor of $claimed_branch" 1>&2
exit 1

The above script does not actually require or check that the ‘branch’ argument is a branch (it could be any commit-ish). To check that something is actually a branch, you might use something like this:

#!/bin/sh

# Usage: is-branch <branch>

if test $# -ne 1; then
    echo "$0"': invalid arguments'
    exit 128
fi
branch="$1"

# check various branch hierarchies, adjust as needed
git show-ref --verify refs/heads/"$branch" ||
git show-ref --verify refs/remotes/"$branch" || {
    echo "not a branch name: $branch" 1>&2
    exit 1
}

So you could use them together to verify that something is a branch and that a certain commit is in that branch:

is-branch "$claimed_branch" && is-ancestor-of "$claimed_branch" "$commit_to_build"
Chris Johnsen
Very interesting. +1
VonC