On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote: > On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote: > > On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote: > > > Because you need to recurse through submodules for `update --branch` > > > even if "$subsha1" == "$sha1", I had to amend the conditional > > > controlling that block. This broke one of the existing tests, which I > > > "fixed" in patch 4. I think a proper fix would involve rewriting > > > > > > (clear_local_git_env; cd "$sm_path" && > > > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && > > > test -z "$rev") || git-fetch)) || > > > die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")" > > > > > > but I'm not familiar enough with rev-list to want to dig into that > > > yet. If feedback for the earlier three patches is positive, I'll work > > > up a clean fix and resubmit. > > > > You probably need to separate your handling here. The comparison of the > > currently checked out sha1 and the recorded sha1 is an optimization > > which skips unnecessary fetching in case the submodules commits are > > already correct. This code snippet checks whether the to be checked out > > sha1 is already local and also skips the fetch if it is. We should not > > break that. > > Agreed. However, determining if the target $sha1 is local should have > nothing to do with the current checked out $subsha1. Erm, I clearly wasn't getting enough sleep heading into yesterday, because when I drop the hack patch #4, reinstall, and retest, I no longer get the bad-fetch error. I'm not quite sure what was going on, but please pretend I never mentioned it ;). -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Attachment:
signature.asc
Description: OpenPGP digital signature