{"thread":{"id":"27772","subject":"Interpreting git merge failures","startedAt":"2011-07-07T18:45:57Z","lastAt":"2011-07-12T16:40:29Z","messageCount":3,"participants":["Scott Bronson","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"170983","messageId":"CAKmUPx5Qt2K+7F+BsW3WTmRjodBSrteuyG8p9oRHZuhApTu4+g@mail.gmail.com","threadId":"27772","inReplyTo":null,"subject":"Interpreting git merge failures","fromName":"Scott Bronson","fromEmail":"bronson@rinspin.com","sentAt":"2011-07-07T18:45:57Z","receivedAt":"2011-07-07T18:45:57Z","isPatch":false,"sender":{"key":"bronson@rinspin.com","avatar":null},"body":"What is the best way to determine why a git merge failed?\nI'm writing a script that needs to do different things depending\non what went wrong.\n\nRight now I'm parsing error messages.  It's obviously a bad\nidea and prone to breakage but it does work.   Example:\n\n    `git fetch origin #{tag || :master}`\n    output = `git merge --ff-only FETCH_HEAD 2>&1`\n\n    # warning, bad idea:\n    if output =~ /Not possible to fast-forward/\n      log \"has different ancestry from upstream, removing and re-cloning.\"\n      remove_and_reclone\n    elsif msg =~ /You have unstaged changes/ ||\n          msg =~ /Your local changes [a-z ]* would be overwritten/ ||\n          msg =~ /commit your changes or stash them before you can merge/\n      log \"has unsaved changes, invalid doc/tags file in upstream repo?\"\n      work_around_tagsfile\n    elsif msg =~ /untracked working tree files would be overwritten/\n      log \"has conflicting file, removing and re-cloning.\"\n      abort  # don't blow away unknown file\n    else\n      log msg\n      abort\n    end\n\nThere's got to be a better way!  I could special-case each check\nbeforehand using git ls-files and friends but that seems almost as\nugly...  Hoping a smarter solution exists.\n\nThis is for https://github.com/bronson/vim-update-bundles\n\nThanks!\n\n    - Scott\n"},{"id":"171138","messageId":"20110712063300.GB12491@sigill.intra.peff.net","threadId":"27772","inReplyTo":"CAKmUPx5Qt2K+7F+BsW3WTmRjodBSrteuyG8p9oRHZuhApTu4+g@mail.gmail.com","subject":"Re: Interpreting git merge failures","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-07-12T06:33:00Z","receivedAt":"2011-07-12T06:33:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jul 07, 2011 at 11:45:57AM -0700, Scott Bronson wrote:\n\n> What is the best way to determine why a git merge failed?\n> I'm writing a script that needs to do different things depending\n> on what went wrong.\n> \n> Right now I'm parsing error messages.  It's obviously a bad\n> idea and prone to breakage but it does work.   Example:\n\nSorry, that's the best you can do with \"git merge\" currently.\n\nThe usual advice would be to check the repo status yourself with\nplumbing tools, but:\n\n  1. That's a lot of work on the part of a script writer.\n\n  2. It's not atomic. You want to know why a merge failed, but\n     circumstances might have changed since the original failure.\n\nIt would be nice if \"git merge\" gave different exit codes for various\nsituations. I don't think it would be all that big a change, and you\nmight be a good person to suggest which conditions need their own exit\ncode, as you are also writing the consuming end of the codes.\n\nWant to write a patch?\n\n-Peff\n"},{"id":"171157","messageId":"7vy6038nb6.fsf@alter.siamese.dyndns.org","threadId":"27772","inReplyTo":"CAKmUPx5Qt2K+7F+BsW3WTmRjodBSrteuyG8p9oRHZuhApTu4+g@mail.gmail.com","subject":"Re: Interpreting git merge failures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-07-12T16:40:29Z","receivedAt":"2011-07-12T16:40:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Scott Bronson <bronson@rinspin.com> writes:\n\n> What is the best way to determine why a git merge failed?\n\nIf you get exit code 0, the merge did not fail.\n\nOtherwise you can inspect the index after getting the non-zero exit code.\n\nIf you have an unmerged entry in the index, there could be two cases.  The\nmost typical is that the merge was attempted and stopped due to an\nconflict. \"ls-files -u\" will show these paths. Another is a user error to\nrun \"git merge\" when your index is already unmerged, but you can easily\navoid this at the beginning of your script, stopping without running \"git\nmerge\" when the index is unmerged to begin with.\n\nIf you do not have an unmerged entry in the index, the merge refrained\nfrom overwriting either your local modifications in the working tree, or\nyour local modifications to the index.  Again the latter is a user error\nthat you can detect before running \"git merge\" in your script.\n"}]}