Hi Jakub, On Thu, Oct 02, 2008 at 06:58:41AM -0700, Jakub Narebski wrote: > SZEDER Gábor <szeder@xxxxxxxxxx> writes: > > --unresolve:: > > Restores the 'unmerged' or 'needs updating' state of a > > file during a merge if it was cleared by accident. > > > > How could I clear those states by accident (or intentionally)? > > "git add <file>", or "git update-index <file>", or error in handling > merge tool via git-mergetool. Thanks for your fast reply. However: # ... do a conflicting merge (master|MERGING)$ echo 4 >one (master|MERGING)$ git status one: needs merge # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working # directory) # # unmerged: one # no changes added to commit (use "git add" and/or "git commit -a") (master|MERGING)$ git add one (master|MERGING)$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: one # (master|MERGING)$ git update-index --unresolve (master|MERGING)$ echo $? 0 (master|MERGING)$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: one # So, as you can see, after 'add ; update-index --unresolve' the file is not marked as unmerged, but it's still ready to be committed. Is something wrong going on here, or it is indeed the intended behaviour and I misunderstood this functionality? Thanks, Gábor -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
