Argggh... never mind. The change to the savannah repo should have fixed it. You don't need to do anything locally.
If you already ran "git remote set-head origin -d" just run "git remote set-head origin -a" to set it back. On Sun, Sep 6, 2009 at 12:09 AM, Chris Hanson<[email protected]> wrote: > Yet another follow-up on this. I've deleted the unwanted HEAD branch > on savannah. In order to get rid of it in your local repo, do this: > > git remote set-head origin -d > > On Sat, Sep 5, 2009 at 5:24 PM, Chris Hanson<[email protected]> wrote: >> This problem with HEAD and master causing "is at ... but expected" is >> caused by there being a HEAD symbolic reference in the upstream bare >> repo. Remove the HEAD reference from that repo and the problem should >> go away. >> >> The error is harmless, by the way. It just indicates confusion on >> git's part; the repo is fine and everything is updated as it should >> have been. >> >> I just filed a service request to savannah to get the HEAD reference >> removed from our central repo. >> >> On Fri, Sep 4, 2009 at 9:46 PM, Taylor R Campbell<[email protected]> wrote: >>> Date: Fri, 4 Sep 2009 21:36:30 -0700 >>> From: Chris Hanson <[email protected]> >>> >>> According to the "git magic" site, most git commands don't work as >>> expected on bare repos. You need to use --git-dir or --bare, which >>> are global git options (see "man git"). The usage, afaict, is either >>> >>> git pull --git-dir=..../stage.git >>> >>> or alternatively >>> >>> cd ..../stage.git; git pull --bare >>> >>> I think git push works similarly. You shouldn't have to specify where >>> to push or pull, when the repo was created with git clone; that >>> information is supposed to be stored in ..../stage.git/config. For >>> reference, I've attached the .git/config from my tree. >>> >>> Well, someone much more experienced with Git than I suggested that I >>> run in the working directory >>> >>> work% git pull ssh://git.sv.gnu.org/srv/git/mit-scheme.git >>> refs/heads/master:refs/remotes/savannah/master >>> >>> That seemed to work to merge the current state of the public >>> repository into my working repository, and created what is as far as I >>> can tell a spurious commit whose only purpose is to chronicle the fact >>> that I ran `git pull' with local changes. Then I pushed into the >>> staging repository, and that seemed happy, so I ran another build to >>> confirm that my changes worked, and finally ran >>> >>> stage.git% git push ssh://git.sv.gnu.org/srv/git/mit-scheme.git >>> Counting objects: 18, done. >>> Delta compression using up to 2 threads. >>> Compressing objects: 100% (10/10), done. >>> Writing objects: 100% (10/10), 1.21 KiB, done. >>> Total 10 (delta 8), reused 0 (delta 0) >>> To ssh://git.sv.gnu.org/srv/git/mit-scheme.git >>> 6bceccb..a679dfd master -> master >>> stage.git% cd ../clean >>> clean% git pull >>> remote: Counting objects: 18, done. >>> remote: Compressing objects: 100% (10/10), done. >>> remote: Total 10 (delta 8), reused 0 (delta 0) >>> Unpacking objects: 100% (10/10), done. >>> From git://git.savannah.gnu.org/mit-scheme >>> + 6bceccb...f2b42a4 HEAD -> origin/HEAD (forced update) >>> error: Ref refs/remotes/origin/master is at >>> f2b42a44bdb4ba11b97b4d7360fc1031700ba8c3 but expected >>> 6bceccb3d92ab8ca5eb267d95dca74c24b7b1c5d >>> ! 6bceccb..a679dfd master -> origin/master (unable to update local >>> ref) >>> >>> What have I done wrong now? `clean' is a completely clean repository >>> where I have run nothing but `git pull' and non-destructive commands, >>> and which I cloned from <git://git.sv.gnu.org/mit-scheme.git>. Did my >>> changes get propagated to the public repository? >>> >> > _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
