On Tue, Oct 27, 2009 at 10:07:27AM -0500, Jeffrey Middleton wrote: > > Do you get the same problem if you do the steps individually, i.e.: > > > > git remote update steph > > git remote prune steph > > git remote update kevin > > I don't *think* I'll see it this way - I was doing essentially this > prior to introduction of the --prune option, and never saw it then. I suspect you are seeing git keeping an invalid cache of the set of refs within a single program. Your original report had: > Pruning steph > URL: /users/sdewet/CxTF_DEV/CxTF_DB/ > * [pruned] steph/beta_gc_dev_old > Updating kevin > error: refs/remotes/steph/beta_gc_dev does not point to a valid object! > error: refs/remotes/steph/beta_veh_dev does not point to a valid object! The "pruned" line basically means that we are deleting that ref, and then we complain immediately about that very ref (which is probably pointing to the null sha1 or something at this point). We tend to cache packed refs, so that may be the cause. So either we need to invalidate that ref from the cache when it gets deleted, or perhaps we are already invalidating it and we need to be respecting that invalidation in other parts of the code. I'll take a look. -Peff -- 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