On Sat, 13 Mar 2010, Junio C Hamano wrote: > Hmm. > > When it detects conflicts, and refuses to make a merge, the octopus > backend says "should not be doing an octopus". As far as I can tell, > MERGE_HEAD is useful only when resolving conflicts, and the octopus There is also another use - see below. > strongly discourages recording anything but the simplest conflict-free > merges. How can I know in advance that the merge will be conflict free? I have a script which merges a bunch of (simple) topic branches which usually merge without conflict, but from time to time some branch evolves and conflicts. > That makes me think that not writing the file out would be the more > correct thing to do. > > One possibility I can think of is that we try to prevent user mistakes by > checking the existence of MERGE_HEAD (i.e. "can't do this, you are still > during a merge"), and not writing MERGE_HEAD in this case, but still > potentially leaving the index unmerged, may allow some operations that we > should prevent from being invoked to proceed. Is that the issue you are > trying to address? Or is there something else? Why do you want to have > MERGE_HEAD? I'm using zsh and vcs_info which shows me git repo status in my prompt (see e.g. http://www.jukie.net/~bart/blog/pimping-out-zsh-prompt). vcs_info tests for existence of MERGE_HEAD to signalize that you are in the middle of merge. If MERGE_HEAD is not created I do not see a big red waning in my prompt and I expect the merge to be successful. In my experiments I found that octopus creates MERGE_HEAD in several situations but not in the one when a branch modifies the file and another deletes it. Therefore I think it is a bug. -Michal -- 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