Interpreting git merge failures

Interpreting git merge failures

[Scott Bronson]

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

Re: Interpreting git merge failures

[Jeff King]

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

> 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:

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

Re: Interpreting git merge failures

[Junio C Hamano]

Scott Bronson <bronson@rinspin.com> writes:

> What is the best way to determine why a git merge failed?

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.