Cannot discard conflicts when cherry-picking or merging #552

mbunkus opened this Issue Feb 5, 2013 · 2 comments


None yet
2 participants

mbunkus commented Feb 5, 2013

What I'm doing: cherry-pick an item from a log view. If that cherry-pick fails because of unmerged changes it's very hard to get rid of those unstaged changes from magit.

One of my usual workflows: work in a customer project branch. Commit something that's useful for the product's main branch as well. Check out the main branch. Cherry-pick what I've just done. However, often such commits touch files that exist in the customer's branch but not in the main branch.

In order to reproduce:

  1. Open the log buffer
  2. Cherry-pick an item that modifies files that are not present in the current branch.
  3. Go back to magit's status buffer. It will show "unstaged changes".
  4. Try to use 'k' or 'u' on those unstaged changes: both will fail.

Here's what git shows directly after 2. (only the relevant parts, not the files that the patch could by applied to):

# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#       deleted by us:      SL/Controller/

This means that the file SL/Controller/ was touched in the diff but that it does not exist.

Using git rm SL/Controller/ on the command line gets rid of that change.

In magit pressing 'k' invokes 'git checkout -- SL/Controller/` which git rejects with "file contains unstaged changes". If I press 'u' magit itself says "already unstaged".

I think the very same issue happens when you try to merge something (so this is not limited to cherry-picking).

So what must change: if the "unstaged change" refers to a deleted file then magit must use git rm and not git checkout.


tarsius commented May 29, 2013

Related #47


tarsius commented Jul 20, 2013

Actually it's a duplicate of #47.

@tarsius tarsius closed this Jul 20, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment