Junio C Hamano, Sat, May 19, 2007 05:59:48 +0200: > > - figure out what commit should be checked out from > superproject index; > > - make sure the named commit exists, or fetch to make it exist. What if the fetch is not possible? You can't checkout? What about the other subprojects, where the checkout succeeded? Will they be reset to the previuos state? To me, the fetch sounds pretty dangerous. Maybe the checkout should be two stage: first - we check all subprojects to be checked out if it is possible, second - either fail (default) or checkout what possible, warn the user, leave the incomplete subprojects changed (but not update the index with them, so that they wont be accidentally committed). > - go there and check out that commit; this implies two things: > > 1. if there are local changes, it will be carried along and we > checkout the named commit; Shouldn't that depend on "-m" option given to git-checkout in superproject? Sometime the user have to be sure he can checkout everything as it were, but without breaking the local state (like what current git-checkout without "-m" does). > 2. the repository's HEAD becomes detached; > Universally agreed upon - 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
