Interpreting git merge failures

What is the best way to determine why a git merge failed? I'm writing a script that needs to do different things depending on what went wrong.

Right now I'm parsing error messages. It's obviously a bad idea and prone to breakage but it does work. Example:

    `git fetch origin #{tag || :master}`
    output = `git merge --ff-only FETCH_HEAD 2>&1`

    # warning, bad idea:
    if output =~ /Not possible to fast-forward/
      log "has different ancestry from upstream, removing and re-cloning."
      remove_and_reclone
    elsif msg =~ /You have unstaged changes/ ||
          msg =~ /Your local changes [a-z ]* would be overwritten/ ||
          msg =~ /commit your changes or stash them before you can merge/
      log "has unsaved changes, invalid doc/tags file in upstream repo?"
      work_around_tagsfile
    elsif msg =~ /untracked working tree files would be overwritten/
      log "has conflicting file, removing and re-cloning."
      abort  # don't blow away unknown file
    else
      log msg
      abort
    end

There's got to be a better way! I could special-case each check beforehand using git ls-files and friends but that seems almost as ugly... Hoping a smarter solution exists.

This is for https://github.com/bronson/vim-update-bundles

Thanks!

    - Scott

On Thu, Jul 07, 2011 at 11:45:57AM -0700, Scott Bronson wrote:

Sorry, that's the best you can do with "git merge" currently.

The usual advice would be to check the repo status yourself with plumbing tools, but:

  1. That's a lot of work on the part of a script writer.

  2. It's not atomic. You want to know why a merge failed, but
     circumstances might have changed since the original failure.

It would be nice if "git merge" gave different exit codes for various situations. I don't think it would be all that big a change, and you might be a good person to suggest which conditions need their own exit code, as you are also writing the consuming end of the codes.

Want to write a patch?

-Peff

Scott Bronson <bronson@rinspin.com> writes:

If you get exit code 0, the merge did not fail.

Otherwise you can inspect the index after getting the non-zero exit code.

If you have an unmerged entry in the index, there could be two cases. The most typical is that the merge was attempted and stopped due to an conflict. "ls-files -u" will show these paths. Another is a user error to run "git merge" when your index is already unmerged, but you can easily avoid this at the beginning of your script, stopping without running "git merge" when the index is unmerged to begin with.

If you do not have an unmerged entry in the index, the merge refrained from overwriting either your local modifications in the working tree, or your local modifications to the index. Again the latter is a user error that you can detect before running "git merge" in your script.