# Interpreting git merge failures 3 messages from 2011-07-07 to 2011-07-12. Participants: Scott Bronson, Jeff King, Junio C Hamano. Thread: https://gitlist.dev/t/27772 ## Scott Bronson, 2011-07-07 18:45 Subject: Interpreting git merge failures Message-ID: URL: https://gitlist.dev/e/CAKmUPx5Qt2K%2B7F%2BBsW3WTmRjodBSrteuyG8p9oRHZuhApTu4%2Bg%40mail.gmail.com ``` 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 ``` ## Jeff King, 2011-07-12 06:33 Subject: Re: Interpreting git merge failures Message-ID: <20110712063300.GB12491@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110712063300.GB12491%40sigill.intra.peff.net In-Reply-To: ``` 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 ``` ## Junio C Hamano, 2011-07-12 16:40 Subject: Re: Interpreting git merge failures Message-ID: <7vy6038nb6.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vy6038nb6.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Scott Bronson 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. ```