From: Bill Lear <hidden> Date: 2016-06-15 22:43:03
I'm trying to explain this behavior to a co-worker, and how to solve
it:
% git pull
Already up-to-date.
% git push
error: remote 'refs/remotes/origin/flexify' is not a strict subset of
localref 'refs/remotes/origin/flexify'. maybe you are not up-to-date
and need to pull first?
I believe he is using git 1.5.0 and that the above was tried from the
master branch.
So, I'm confused: I would have thought the way you solve the problem
in step 2 is by executing step 1. Would he need to do this:
% git checkout flexify
% git pull flexify:flexify
% git checkout master
% git push
Bill
From: Jeff King <hidden> Date: 2016-06-15 22:43:03
On Thu, Apr 05, 2007 at 07:15:54AM -0500, Bill Lear wrote:
I'm trying to explain this behavior to a co-worker, and how to solve
it:
% git pull
Already up-to-date.
% git push
error: remote 'refs/remotes/origin/flexify' is not a strict subset of
localref 'refs/remotes/origin/flexify'. maybe you are not up-to-date
and need to pull first?
That ref name is a bit suspect...why are you pushing your your remote
tracking branches? If you are simply pushing to a repository that is a
pure mirror, maybe your 'push' line in the config file should have a '+'
at the front?
At any rate, the reason why the pull doesn't fix it is that it is not
pulling onto flexify, but onto master, which it looks like you guessed:
So, I'm confused: I would have thought the way you solve the problem
in step 2 is by executing step 1. Would he need to do this:
% git checkout flexify
% git pull flexify:flexify
% git checkout master
% git push
It would need to be:
git pull $remote flexify:flexify
I don't think that works, though, because it's _not_ the flexify branch
that's the problem. It's the refs/remotes/origin/flexify, which
generally shouldn't be getting pushed at all. Can you show us the
.git/config?
-Peff
From: Bill Lear <hidden> Date: 2016-06-15 22:43:03
On Thursday, April 5, 2007 at 09:49:54 (-0400) Jeff King writes:
On Thu, Apr 05, 2007 at 07:15:54AM -0500, Bill Lear wrote:
quoted
I'm trying to explain this behavior to a co-worker, and how to solve
it:
% git pull
Already up-to-date.
% git push
error: remote 'refs/remotes/origin/flexify' is not a strict subset of
localref 'refs/remotes/origin/flexify'. maybe you are not up-to-date
and need to pull first?
That ref name is a bit suspect...why are you pushing your your remote
tracking branches? If you are simply pushing to a repository that is a
pure mirror, maybe your 'push' line in the config file should have a '+'
at the front?
At any rate, the reason why the pull doesn't fix it is that it is not
pulling onto flexify, but onto master, which it looks like you guessed:
quoted
So, I'm confused: I would have thought the way you solve the problem
in step 2 is by executing step 1. Would he need to do this:
% git checkout flexify
% git pull flexify:flexify
% git checkout master
% git push
It would need to be:
git pull $remote flexify:flexify
I don't think that works, though, because it's _not_ the flexify branch
that's the problem. It's the refs/remotes/origin/flexify, which
generally shouldn't be getting pushed at all. Can you show us the
.git/config?
Here is the config for the remote repository:
[core]
repositoryformatversion = 0
filemode = true
bare = false
[remote "origin"]
url = git://source/fusion
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Here is the local:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://poire/home/jml/repos/new/fusion
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Hmm.... I wonder if his remote repo is non-bare... I'll try to find
out.
Bill
From: Bill Lear <hidden> Date: 2016-06-15 22:43:03
On Thursday, April 5, 2007 at 09:07:11 (-0500) Bill Lear writes:
...
Hmm.... I wonder if his remote repo is non-bare... I'll try to find
out.
Yes, it is. Here is the reply I got from my friend:
Bill Lear writes:
quoted
So, the remote repo to which you pushed originally is non-bare? That
is, it has working files checked out?
Correct.
quoted
If so, that is a problem, but
perhaps not the cause of your problems. Never push to a non-bare
repo: you need to go that repo and do a pull instead.
I've been able to work around such problems. I know well about the
double-commit reversal whammy that can happen (since it happened to me).
If I push to a non-bare repo that's otherwise got no file modifications
in it, I can do a "git status" to see what files it thinks are out of
date, which tells me (by the file list) that the push succeeded. Then
I just do a "git checkout -f" to sync up. Up til now, has worked like
a charm. Alternately, I switch to some bogus temporary branch in the
non-bare repo I'm pushing to & switch back after.
From: Bill Lear <hidden> Date: 2016-06-15 22:43:03
On Thursday, April 5, 2007 at 16:46:04 (-0400) Jeff King writes:
On Thu, Apr 05, 2007 at 09:07:11AM -0500, Bill Lear wrote:
quoted
Here is the local:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://poire/home/jml/repos/new/fusion
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
I don't see anything there that should cause branches under refs/remotes
to be pushed. Was he using 'git-push --all' by any chance?
No, just plain ol' git push. One possibility is that in mediating
between him and the list, there has been a loss of information.
Perhaps he omitted details in his account of how things progressed ---
who knows, perhaps he was on the wrong branch (though I doubt this, he
only works on the master branch, and the other branch in question was
someone else's entirely).
Regardless, does my assumption --- a 'git pull' should rectify
the 'you are not up to date' problem --- hold in general?
Thanks for helping.
Bill
From: Jeff King <hidden> Date: 2016-06-15 22:43:03
On Thu, Apr 05, 2007 at 03:55:18PM -0500, Bill Lear wrote:
No, just plain ol' git push. One possibility is that in mediating
between him and the list, there has been a loss of information.
Perhaps he omitted details in his account of how things progressed ---
who knows, perhaps he was on the wrong branch (though I doubt this, he
only works on the master branch, and the other branch in question was
someone else's entirely).
No, I think you gave the correct information. See the other part of the
thread between me and Junio. What's happening is that 'git-push' tries
to push every ref that both you and the remote have. Because he's
pushing into a non-bare repository, both sides have
refs/remotes/origin/flexify. But they're not necessarily at the same
point, since they're both fetched from whatever your origin is, thus the
problem. In this case, his flexify tracking branch for origin is
_behind_ the remote's, so the push doesn's work.
Regardless, does my assumption --- a 'git pull' should rectify
the 'you are not up to date' problem --- hold in general?
Generally, yes. But the remotes/ hierarchy is not something you pull
into. So in this case, it won't help. The real solution is that git-push
should not be pushing remotes/ at all: it should be purely a local
thing (the patch I posted elsewhere in the thread fixes this, but will
not be the final behavior -- however, it's enough to fix this problem).
As a temporary solution, fetching from origin should put him at the same
place (or ahead of) the remote, which should allow the push to go
through.
-Peff