On 2007-08-05 10:46, Sven Verdoolaege wrote: >> $ git checkout experimental-death-ray >> $ git submodules update >> (return a week later, woozy from the vacation.) >> $ git checkout master > > Here, it'll warn that your submodule isn't up-to-date. > >> (hack hack hack) >> $ git commit -a -m "fixed typos" > > And if you run "git status" first, it'll tell you that the submodule > (still) isn't up-to-date. > >> $ git push >> (Oops. You've just accidentally committed the wrong submodule heads.) > > You always have to be careful when doing "git commit -a". Exactly. You now have to be very careful, whereas previously $ git checkout master && vi foo && git commit -a -m "fixed typos" was perfectly safe. Worse yet, it could also be a script making similar assumptions. For example, consider the tree filter in git-filter-branch. It used to be fine, but will now corrupt the rewritten trees when submodules are involved. Here's the relevant code from git-filter-branch.sh: ----------------------------------------------------------------- while read commit parents; do ... git read-tree -i -m $commit ... git checkout-index -f -u -a || die "Could not checkout the index" ... eval "$filter_tree" < /dev/null || die "tree filter failed: $filter_tree" git diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \ xargs -0 git update-index --add --replace --remove ... sh -c "$filter_commit" "git commit-tree" \ $(git write-tree) $parentstr < ../message > ../map/$commit done <../revs ----------------------------------------------------------------- >> Another approach is for pull, checkout etc. to automatically update the >> submodule' head ref, but no more. > > Then everything, including "git submodule update", would assume > that the submodule is up-to-date. With that approach, "git submodule update" would fetch the submodule's head commit (which could be missing), and then check it against the submodule's index (and maybe its work tree). 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