'fatal: bad revision' when using git log with BITBUCKET_COMMIT

liamcmcdermott

As part of a Bitbucket Pipeline I'm trying to get a list of files that have changed in the last commit (and its parents, back to the divergence from the `master` branch). This is the command the script is running:

git log --name-only --oneline --pretty=format: master..$BITBUCKET_COMMIT --

But this generates an error when the pipeline runs:

fatal: bad revision 'master..f85282eb10125f0de04afba8a87d5745baff5aff'

However, if I copy/paste the revision hash and run the exact command on my local dev machine it prints a list of files (as expected).

Why does this error on Bitbucket Pipelines (but not my local dev environment)?

git version is 2.17.1 (and on my local machine it's 2.17.1 also, the Docker container and my local dev machine are both Ubuntu 18.04).

---

Note, the actual script is in Haskell (using the Turtle library), the relevant part of the script is:

#!/usr/bin/env runhaskell

{-# LANGUAGE OverloadedStrings #-}

import Turtle
import qualified Control.Foldl as Fold

envCommit = "BITBUCKET_COMMIT"

main = do
  commit <- do
    ct <- need envCommit
    case ct of
      Just ct' -> pure ct'
      Nothing -> err "ERROR: No commit was specified." >> exit (ExitFailure 1)

  let gits = [ "log" , "--name-only" , "--oneline" , "--pretty=format:" , format ("master.."%s) commit, "--" ]
  let gitFiles = inproc "git" gits empty -- <- Here is where the script is failing.
  let filteredFiles = nub $ grep (suffix ".ts") gitFiles
  files <- fold filteredFiles Fold.list

  if length files > 0
    then procs "tslint" (map lineToText files) empty
    else echo "No code files to lint."

But I don't want anyone to have to deal with the cognitive overhead of reading (my bad) Haskell code. This also works fine on my local dev machine (so it isn't the Haskell that's the problem).

Matt Ryall

The error message "bad revision" indicates that the local repository in your build doesn't contain one of the commits you're referencing.

This happens because Pipelines does a shallow clone by default, containing just the most recent 50 commits on the current branch. So in your example, master probably isn't available in the local repo. Shallow cloning makes your builds faster, because we pull down less data from your Bitbucket repository before starting the builds.

You can configure the clone depth like this:

clone:
  depth: 250  # or 'full' for everything

pipelines:
  branches:
    ...

To get another branch included, you'll need to use a full clone, or fetch that branch with Git (requires setting up auth back to Bitbucket).