Jeffrey Middleton venit, vidit, dixit 26.10.2009 23:08: > I have an unreliable problem when using "git remote update --prune". > git claims that many refs from a particular remote do not point to a > valid object, but only after finishing another update. I've included > a shortened version of the output from one particular instance of the > issue. Note that the errors are printed for every subsequent remote > as well. However, after the update is completed, everything is fine. > > It seems to only happen when there are non-fast-forward changes (new > branch, forced update, pruned branch). The issue only happens with > this particular remote, which I've tried removing and recreating, and > is the same type of remote as all my others (another user's > NFS-mounted home directory). However, my remotes are all individual > developers, and this developer is the only one who ever rebases her > working branches. (recloning the repo from origin and setting up my > config and remotes all over again has also had no effect) > > Unfortunately, I have been unable to reproduce the problem in any test > repos - for example, though a forced update and a pruned branch in the > problematic remote along with an update in another remote seems to > fairly reliably produce the problem in this repo, recreating that > situation in another repo doesn't cause any problems. Sorry for the > incomplete bug report, but perhaps this will be enough to go on! > > Thanks, > Jeffrey > > > I've seen the issue in previous versions built from git.git master, as > well as v1.6.3.3, but for this particular one: > > $ git --version > git version 1.6.5.1.61.ge79999 > > $ git remote update --prune > Updating origin > remote: Counting objects: 42, done. > remote: Compressing objects: 100% (9/9), done. > remote: Total 15 (delta 9), reused 12 (delta 6) > Unpacking objects: 100% (15/15), done. > From /users/cxtfcm/CxTF_DB > 88b8613..d40f26d 2009.Q4 -> origin/2009.Q4 > d40f26d..56305b8 dev -> origin/dev > Updating steph > remote: Counting objects: 299, done. > remote: Compressing objects: 100% (241/241), done. > remote: Total 276 (delta 186), reused 19 (delta 6) > Receiving objects: 100% (276/276), 41.09 KiB | 10 KiB/s, done. > Resolving deltas: 100% (186/186), completed with 17 local objects. > From /users/sdewet/CxTF_DEV/CxTF_DB > + c2439dd...69cb5c3 beta_gc_dev -> steph/beta_gc_dev (forced update) > + fb25173...f0e4963 beta_veh_dev -> steph/beta_veh_dev (forced update) > * [new branch] beta_veh_dev_old -> steph/beta_veh_dev_old > 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! > Updating jose > 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! > ### many more remotes with the same errors ### 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 Does it depend on the order, i.e.: git remote update steph git remote update kevin git remote prune steph Does "git fsck --full" say anything special? 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