Am 07.05.2011 21:24, schrieb Junio C Hamano: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> In other words, can't the check you need in submodule be scripted around >> the specific plumbing responsible for the branch switching, which is: >> >> $ git read-tree -m HEAD $other_branch >> >>> @@ -397,7 +400,7 @@ static int merge_working_tree(struct checkout_opts *opts, >>> >>> /* 2-way merge to the new branch */ >>> topts.initial_checkout = is_cache_unborn(); >>> - topts.update = 1; >>> + topts.update = !opts->dry_run; >>> topts.merge = 1; >>> topts.gently = opts->merge && old->commit; >>> topts.verbose_update = !opts->quiet; >> >> What you are doing in this part of your patch is exactly that two-tree >> form of the "read-tree -m", no? > > That is, this would succeed: > > $ git reset --hard master > $ git read-tree --index-output=rubbish -m master next > > and these would fail: > > $ git reset --hard master > $ echo >>Makefile > $ git read-tree --index-output=rubbish -m master next > error: Entry 'Makefile' not uptodate. Cannot merge. > > $ git reset --hard master > $ echo >>Makefile > $ git add Makefile > $ git read-tree --index-output=rubbish -m master next > error: Entry 'Makefile' would be overwritten by merge. Cannot merge. Thanks for pointing me to "git read-tree -m". When I saw that a "git checkout -n" would do exactly what I needed, I stopped looking for alternatives (especially as I saw that adding -n there would help other non-submodule use cases as well). > Having said that, please do not discard your patch. After sleeping on > this, I started to think that "checkout -n" might be a better interface > than using the plumbing read-tree in the longer term, especially if you > can enhance it to handle "checkout -m -n" to check if the local change can > be merged without conflicts. I'll see if I can come up with a solution for the "-m -n" case (I stopped after implementing the checkout branch case I needed to get some feedback if this thing went into the right direction). And I assume the "git checkout <pathspec>" case should learn -n too? > But if the only question you are interested in is "can I switch to that > branch from the current state of the index and the working tree?", I would > prefer to see if the script can use "read-tree -m" approach first. Yup, I will try that. > We may also want to add "read-tree -n" so that you do not have to specify > a dummy index output only to prevent from writing the real index over, > though. Hmm, wouldn't using "read-tree --index-output=/dev/null" be equivalent to "read-tree -n"? But nonetheless it might make sense to add the -n option. -- 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