On 2007-08-04 01:13, Junio C Hamano wrote: > Let me understand the problem first. If your first checkout > does not check out the submodule, switching between revisions > that has different commit of the submodule there would not fail, > but once you checkout the submodule, switching without updating > the submodule would be Ok (because by design updating the > submodule is optional) but then further switching out of that > state will fail because submodule in the supermodule tree and > checked-out submodule repository are now out of sync. Is that > the problem? > [snip] > Where does the "No you are not up-to-date, I wouldn't let you > switch" come from? Is that verify_uptodate() called from > merged_entry() called from twoway_merge()? I think the right > approach to deal with this is to teach verify_uptodate() about > the policy. The function is about "make sure the filesystem > entity that corresponds to this cache entry is up to date, lest > we lose the local modifications". As we explicitly allow > submodule checkout to drift from the supermodule index entry, > the check should say "Ok, for submodules, not matching is the > norm" for now. Later when we have the ability to mark "I care > about this submodule to be always in sync with the superproject" > (thereby implementing automatic recursive checkout and perhaps > diff, among other things), we should check if the submodule in > question is marked as such and perform the current test. > > How about doing something like this instead? > > unpack-trees.c | 9 +++++++++ Works here: it silences the check and allows switching branches. Still, leaving the working tree dirty can inadvertently affect subsequent commits. Consider the most ordinary of sequences: $ git checkout experimental-death-ray $ git submodules update (return a week later, woozy from the vacation.) $ git checkout master (hack hack hack) $ git commit -a -m "fixed typos" $ git push (Oops. You've just accidentally committed the wrong submodule heads.) So to safely make new commits you must remember to always run "git submodule update", or forgo use of "git commit -a", whenever submodules might be involved. I guess you can hack around this by excluding submodules from "commit -a" and (for scripts) "ls-files -m" too... Another approach is for pull, checkout etc. to automatically update the submodule' head ref, but no more. In this case the supermodule always sees a consistent state with traditional semantics, but the *submodule* ends up with a dirty working tree and a head referring to a possibly-missing commit; "git submodule update" would need to clean that up. Eran - 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
