On Tue, Oct 27, 2009 at 3:42 AM, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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. > Does it depend on the order, i.e.: > > git remote update steph > git remote update kevin > git remote prune steph I've tried once and saw no problems. I just realized I should be saving off all remote refs before doing a remote update --prune again - next time I see the problem I should be able to rule out everything for sure. Sorry I didn't do that sooner. However, I'm still fairly sure it's specific to the all-at-once operation of remote update --prune since I never saw it before that feature, and because once that command finishes, everything is okay. > Does "git fsck --full" say anything special? Just 47 dangling blobs, 23 dangling trees, and 13 dangling commits. > Michael > -- 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