mit-scheme-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] using git


From: Chris Hanson
Subject: Re: [MIT-Scheme-devel] using git
Date: Sun, 6 Sep 2009 00:56:12 -0700

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<address@hidden> 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<address@hidden> 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<address@hidden> wrote:
>>>   Date: Fri, 4 Sep 2009 21:36:30 -0700
>>>   From: Chris Hanson <address@hidden>
>>>
>>>   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?
>>>
>>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]