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 wrote:
> Yet another follo
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 wrote:
> This problem with HEAD and master causing "is at ... but expected" is
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;
Date: Fri, 4 Sep 2009 21:36:30 -0700
From: Chris Hanson
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 --gi
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 --ba
I think I can guess what the problem is: because the staging
repository is a bare repository, `git pull' and `git merge' don't
work, because there's no working tree. (That is a wild guess -- I see
no text in the git-pull(1), git-fetch(1), or git-merge(1) man pages
about bare repositories -- but th
Date: Thu, 3 Sep 2009 15:44:51 -0700
From: Chris Hanson
Instead of trying to pull your changes into an existing repo, you
could just "git clone" the repo each time.
I don't know why "git pull" is failing this way, so that's the best I
can offer atm.
OK. Using `git clone' to c
On Thu, Sep 3, 2009 at 3:24 PM, Taylor R Campbell wrote:
>
> FYI, I generally don't use this workflow. If I want to stage stuff
> for release, I use branches. I also use a build directory that's just
> a bunch of symlinks pointing into the source directory.
>
> All I want to do is test my c
Date: Thu, 3 Sep 2009 14:45:42 -0700
From: Chris Hanson
A "bare" repository is one without an associated working tree. If you
just want a local repository that you can push and pull to, that's the
right thing. The error message was trying to tell you that you were
going to mak
On Thu, Sep 3, 2009 at 9:22 AM, Taylor R Campbell wrote:
> Apparently what I did wrong was making the stage repository with `git
> clone' instead of `git clone --bare', which someone suggested to me
> (and Git did use the word `bare', I suppose). I looked in the man
> pages -- git-clone(1), git-p
Date: Thu, 3 Sep 2009 04:00:07 -0400
From: Taylor R Campbell
After numerous failed attempts to update my local repositories,
including several hard resets, I decided to nuke them all and start
anew, saving my changes as unified diffs (and manually editing all
$Id$-line garbage o
After numerous failed attempts to update my local repositories,
including several hard resets, I decided to nuke them all and start
anew, saving my changes as unified diffs (and manually editing all
$Id$-line garbage out of them). But now Git tells me that I'm doing
something wrong whenever I try
12 matches
Mail list logo
