Problem with a push

Problem with a push

[Alex R.M. Turner]

I get the following error when pushing after a merge:

updating 'refs/heads/master'
  from c18f9e4350c26e6b45d0a282ff32991784becbdd
  to   39b7d927720c9f2810e0af5311975119c0d7c7bd
updating 'refs/remotes/origin/HEAD'
  from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
  to   c18f9e4350c26e6b45d0a282ff32991784becbdd
updating 'refs/remotes/origin/master'
  from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
  to   c18f9e4350c26e6b45d0a282ff32991784becbdd
Generating pack...
Done counting 26 objects.
Result has 10 objects.
Deltifying 10 objects...
 100% (10/10) done
Writing 10 objects...
 100% (10/10) done
Total 10 (delta 7), reused 0 (delta 0)
refs/heads/master: c18f9e4350c26e6b45d0a282ff32991784becbdd -> 
39b7d927720c9f2810e0af5311975119c0d7c7bd
ng refs/remotes/origin/master failed to lock
refs/remotes/origin/HEAD: 1e631edb3078ec3a4d1fa598c8f410f6a61659b0 -> 
c18f9e4350c26e6b45d0a282ff32991784becbdd
error: Ref refs/remotes/origin/master is at 
c18f9e4350c26e6b45d0a282ff32991784becbdd but expected 
1e631edb3078ec3a4d1fa598c8f410f6a61659b0
error: failed to lock refs/remotes/origin/master
error: failed to push to 'ssh://aturner@svn.mintpixels.com/data/git/mls'

but when I try it again, it just says Everything up-to-date.

Alex

Re: Problem with a push

[Linus Torvalds]

On Mon, 11 Jun 2007, Alex R.M. Turner wrote:
> 
> I get the following error when pushing after a merge:
> 
> updating 'refs/heads/master'
>   from c18f9e4350c26e6b45d0a282ff32991784becbdd
>   to   39b7d927720c9f2810e0af5311975119c0d7c7bd
> updating 'refs/remotes/origin/HEAD'
>   from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
>   to   c18f9e4350c26e6b45d0a282ff32991784becbdd
> updating 'refs/remotes/origin/master'
>   from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
>   to   c18f9e4350c26e6b45d0a282ff32991784becbdd

Ok, pushing out remote branches is a bit odd in the first place. As in 
"you probably shouldn't do that". The "remote" branches are really local 
to each repo, and updating them by pushing is really quite suspect.

So the regular "master" branch pushed out fine:

> refs/heads/master: c18f9e4350c26e6b45d0a282ff32991784becbdd -> 39b7d927720c9f2810e0af5311975119c0d7c7bd

and that part is all ok.

However, I think the problem is this:

> refs/remotes/origin/HEAD: 1e631edb3078ec3a4d1fa598c8f410f6a61659b0 ->  c18f9e4350c26e6b45d0a282ff32991784becbdd

You updated the HEAD file, but that actually is a _symbolic_ ref, which 
normally points to refs/removes/origin/HEAD, and that in turn explains the 
other errors:

> ng refs/remotes/origin/master failed to lock
> error: Ref refs/remotes/origin/master is at c18f9e4350c26e6b45d0a282ff32991784becbdd but expected 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
> error: failed to lock refs/remotes/origin/master
> error: failed to push to 'ssh://aturner@svn.mintpixels.com/data/git/mls'

What happened is that the "remotes/origin/master" branch already got 
updated when you updated HEAD, so now git is complaining that you are 
trying to update it again, but it no longer has the same value that it had 
originally (since you changed it).

> but when I try it again, it just says Everything up-to-date.

Right. Because the HEAD update really already did all the changes (to 
_both_ remotes/origin/HEAD _and_ remotes/origin/master, since it was a 
symref), so next time around there is nothing to push, and you won't see 
this issue any more.

So I don't think there was anything reall bad going on, except for the 
fact that you really shouldn't try to push out remote branches.

What was the command line?  In particular, was this a "git push --all" or 
something? I think we should make sure that we do *not* push remotes by 
default (and if you really *really* want to push remotes, you'd have to 
specify them explicitly).

			Linus

Re: Problem with a push

[Alex R.M. Turner]

On Mon, 11 Jun 2007, Linus Torvalds wrote:

> 
> 
> On Mon, 11 Jun 2007, Alex R.M. Turner wrote:
> > 
> > I get the following error when pushing after a merge:
> > 
> > updating 'refs/heads/master'
> >   from c18f9e4350c26e6b45d0a282ff32991784becbdd
> >   to   39b7d927720c9f2810e0af5311975119c0d7c7bd
> > updating 'refs/remotes/origin/HEAD'
> >   from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
> >   to   c18f9e4350c26e6b45d0a282ff32991784becbdd
> > updating 'refs/remotes/origin/master'
> >   from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
> >   to   c18f9e4350c26e6b45d0a282ff32991784becbdd
> 
> Ok, pushing out remote branches is a bit odd in the first place. As in 
> "you probably shouldn't do that". The "remote" branches are really local 
> to each repo, and updating them by pushing is really quite suspect.
> 
> So the regular "master" branch pushed out fine:
> 
> > refs/heads/master: c18f9e4350c26e6b45d0a282ff32991784becbdd -> 39b7d927720c9f2810e0af5311975119c0d7c7bd
> 
> and that part is all ok.
> 
> However, I think the problem is this:
> 
> > refs/remotes/origin/HEAD: 1e631edb3078ec3a4d1fa598c8f410f6a61659b0 ->  c18f9e4350c26e6b45d0a282ff32991784becbdd
> 
> You updated the HEAD file, but that actually is a _symbolic_ ref, which 
> normally points to refs/removes/origin/HEAD, and that in turn explains the 
> other errors:
> 
> > ng refs/remotes/origin/master failed to lock
> > error: Ref refs/remotes/origin/master is at c18f9e4350c26e6b45d0a282ff32991784becbdd but expected 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
> > error: failed to lock refs/remotes/origin/master
> > error: failed to push to 'ssh://aturner@svn.mintpixels.com/data/git/mls'
> 
> What happened is that the "remotes/origin/master" branch already got 
> updated when you updated HEAD, so now git is complaining that you are 
> trying to update it again, but it no longer has the same value that it had 
> originally (since you changed it).
> 
> > but when I try it again, it just says Everything up-to-date.
> 
> Right. Because the HEAD update really already did all the changes (to 
> _both_ remotes/origin/HEAD _and_ remotes/origin/master, since it was a 
> symref), so next time around there is nothing to push, and you won't see 
> this issue any more.
> 
> So I don't think there was anything reall bad going on, except for the 
> fact that you really shouldn't try to push out remote branches.
> 
> What was the command line?  In particular, was this a "git push --all" or 
> something? I think we should make sure that we do *not* push remotes by 
> default (and if you really *really* want to push remotes, you'd have to 
> specify them explicitly).
> 
> 			Linus
> 
Cool - that totally makes sense, HEAD is a link to master. so updating 
HEAD failed because it was already up to date.  The command was simply:

git push

This repo was cloned from one on another server (the server I use to 
backup everything) with a git clone command:

git clone ssh://aturner@svn.mintpixels.com/data/git/mls

.git/config looks like this:
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = ssh://aturner@svn.mintpixels.com/data/git/mls
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
[user]
        email = alex@mintpixels.com
        name = Alex R.M. Turner


git branch -a shows:
* master
  origin/HEAD
  origin/master

Based on all this, what is the correct way to update my core repo on my 
server? (I'm sorry - I'm pretty new to git, so I haven't quite cottoned on 
to some aspects yet).

Alex

Re: Problem with a push

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> What was the command line?  In particular, was this a "git push --all" or 
> something? I think we should make sure that we do *not* push remotes by 
> default (and if you really *really* want to push remotes, you'd have to 
> specify them explicitly).

I suspect that people (probably rightfully) just say "git push"
without saying anything else, and the so-useful-for-old-timers
default "matching refs" behaviour bites them when they do so.

If you create a non-bare clone, clone from that, and then try to
push from the second generation clone to the first generation
non-bare clone, surely there will be "matching" remotes/origin/,
except that they are not really matching X-<.

Re: Problem with a push

[Linus Torvalds]

On Mon, 11 Jun 2007, Alex R.M. Turner wrote:
> 
> Cool - that totally makes sense, HEAD is a link to master. so updating 
> HEAD failed because it was already up to date.

Yes. Well, strictly speaking it failed because it _wasn't_ up-to-date 
*before* the push (so "git push" thought it should update it), but it had 
become up-to-date (through the symref link) by the time it was actually 
its turn to be updated.

> The command was simply:
> 
> git push

Ok, as Junio points out, it's then just the fact that both repositories 
had the same "remote" refs, and then the default of just updating 
everything in common kicks in.

That default used to make sense back when, but it doesn't make sense for 
remotes, since those are generally "local" to each repo.

> This repo was cloned from one on another server (the server I use to 
> backup everything) with a git clone command:

Yeah. Normally you'd (well, _I_ would) only push to bare repositories, and 
normally you wouldn't make those bare repositories have "remotes" entries, 
which is why you're the first to apparently even notice this insanity.

It wasn't your fault, it's simply bad defaults for git behaviour.

The behaviour for "git pull" has improved _immensely_ over the last few 
months, but "git push" still does the same thing it always did, because 
fewer people care about pushing than pulling, and because the old "git 
push" behaviour of just updating all the branches in common actually 
happens to be the right thing when you do *not* make the central 
repository contain remote branches of its own.

> Based on all this, what is the correct way to update my core repo on my 
> server? (I'm sorry - I'm pretty new to git, so I haven't quite cottoned on 
> to some aspects yet).

With the current git model, I would suggest:

 - for "central" repositories, use a bare repository, and don't create 
   "remotes" branches in that central repository at all.

 - for other repositories, don't push into them, just _pull_ into them 
   (because that also knows about updating the working tree etc: pushing 
   is really meant to be done only into bare and central ones that don't 
   actually have any work happening in them, and _cannot_ have any work 
   happening in them because they don't even have a working directory 
   associated with them)

That said, I don't think that's necessarily the right answer in the longer 
run. It's how git people do things, but it's not necessarily the *best* 
way of doing things. I think the better solution in the longer term is to 
simply improve how "git push" works:

 - we should probably do the same kinds of .git/config file entries for 
   pushing as we do for fetching, and just get rid of the old implicit 
   model, and instead have a nice refspec pattern model for what gets 
   pushed instead.

   I _think_ the refspec cleanup work by Daniel makes this something we 
   can almost already do. Daniel?

 - we should also likely have some way to specify what happens when you 
   push into a branch that is currently checked out and has a working tree 
   associated with it.

   This was briefly discussed a few weeks ago, but nobody cared enough, I 
   suspect.

anyway, I think the _proper_ thing to do would be to associate each 
[remote] entry in the config file with a "push" refspec pattern, the way 
we do for "fetch" already.

		Linus

Re: Problem with a push

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> That said, I don't think that's necessarily the right answer in the longer 
> run. It's how git people do things, but it's not necessarily the *best* 
> way of doing things. I think the better solution in the longer term is to 
> simply improve how "git push" works:
>
>  - we should probably do the same kinds of .git/config file entries for 
>    pushing as we do for fetching, and just get rid of the old implicit 
>    model, and instead have a nice refspec pattern model for what gets 
>    pushed instead.
>
>    I _think_ the refspec cleanup work by Daniel makes this something we 
>    can almost already do. Daniel?

That has already been there long before Daniel's patches.

>  - we should also likely have some way to specify what happens when you 
>    push into a branch that is currently checked out and has a working tree 
>    associated with it.
>
>    This was briefly discussed a few weeks ago, but nobody cared enough, I 
>    suspect.

That actially is in the todo:TODO for some time.  Just have been
too busy to look into it.

> anyway, I think the _proper_ thing to do would be to associate each 
> [remote] entry in the config file with a "push" refspec pattern, the way 
> we do for "fetch" already.

I do not think that is enough.  A sane thing if we were doing
"git push" from scratch and there is no existing user's fingers
to re-train, would be:

 * "git-push" without anything will default to "git-push
   origin"; this has been working for a long time.

 * "git-push $remote" when there is [remote] refspec config use
   that refspecs, not "matching refs"; this also has been
   working for a long time.

 * We would want to change git-push so that "git-push $remote"
   will _NOT_ default to 'matching refs'.  We keep that
   'matching refs' behaviour only when the other end is a bare
   repository.

 * For "git-push $remote" to a non-bare repository, that does
   not have [remote] push refspecs, we probably would want to
   change the default to refuse operation, or push only
   'matching heads' (as opposed to 'matching refs').

Alternatively, we could teach "git clone" and "git remote add"
to add push refspec in the config, and keep the 'matching refs
if there is no push refspec in the config' behaviour.

However, the push refspec needs to be different depending on the
bareness of the remote, and I do not see a good way to arrange
this.

"git clone" does communicate with the remote, so theoretically
we ought to be able to do that, but there currently is no way to
indicate bareness of the remote to the client.

"git remote add" by default does not even communicate with the
remote, so without telepathy that is even more cumbersome to
arrange than "git clone" case.

Re: Problem with a push

[Andy Parkins]

On Tuesday 2007 June 12, Linus Torvalds wrote:

> Ok, pushing out remote branches is a bit odd in the first place. As in
> "you probably shouldn't do that". The "remote" branches are really local
> to each repo, and updating them by pushing is really quite suspect.

I agree its odd, but is it really true that one (I) shouldn't be doing it?

Can I tell you what I'm doing, and check that it's not crazy...

I have my laptop and my desktop computer; I use both for development.  I've 
set them so that they are symmetric...

laptop:.git/config
 [remote "desktop"]
   url = ssh://blah blah blah
   fetch = refs/heads/*:refs/remotes/desktop/*
   push = refs/heads/*:refs/remotes/laptop/*

desktop:.git/config
 [remote "laptop"]
   url = ssh://blah blah blah
   fetch = refs/heads/*:refs/remotes/laptop/*
   push = refs/heads/*:refs/remotes/desktop/*

This is very handy, as git-push on one does the same as git-fetch on the 
other.  Have I made a glaring mistake by pushing to a remote ref?


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: Problem with a push

[Linus Torvalds]

On Tue, 12 Jun 2007, Andy Parkins wrote:
> 
> I agree its odd, but is it really true that one (I) shouldn't be doing it?

No, it's definitely not a hard rule, and it's perfectly fine to push any 
refs at all, including remotes.

It's just that we probably shouldn't do it by *default*.

There's another slight detail to this story, which is what caused Alex to 
notice in the first place: we tried to push to something that was a 
symref, which actually caused *another* ref to update. Again, there's 
nothing wrong about that theoretically (it's what symrefs are there for!), 
but again, it's probably something we shouldn't do by default.

So there's a big difference between:

 - git _can_ do it, and it's perfectly sane to do when you know what you 
   are doing and have a very specific issue.

and

 - git not only _can_ do it, but will do it even when you didn't 
   explicitly tell it to do that..

> Can I tell you what I'm doing, and check that it's not crazy...
> 
> I have my laptop and my desktop computer; I use both for development.  
> I've set them so that they are symmetric...
> 
> laptop:.git/config
>  [remote "desktop"]
>    url = ssh://blah blah blah
>    fetch = refs/heads/*:refs/remotes/desktop/*
>    push = refs/heads/*:refs/remotes/laptop/*
> 
> desktop:.git/config
>  [remote "laptop"]
>    url = ssh://blah blah blah
>    fetch = refs/heads/*:refs/remotes/laptop/*
>    push = refs/heads/*:refs/remotes/desktop/*
> 
> This is very handy, as git-push on one does the same as git-fetch on the 
> other.  Have I made a glaring mistake by pushing to a remote ref?

I think this is perfectly sane, exactly because you did it explicitly, and 
partly exactly *because* you explicitly don't do what git push does by 
default (which is to update the "remote" refs remotely with what are the 
remote refs locally!).

IOW, the notion of "remote" refs really logically implies a mirror image, 
exactly like you have it set up in your config: what is a local ref in one 
repository is a remote ref in another. But that's not what the default 
"git push" semantics are: it just matches refs directly, without that 
mirroring.

And the _reason_ for it doing that are obviously historical: we didn't use 
to have the notion of "remotes", so back when I did that, it made sense. 
It just doesn't make sense any more.

Junio: I suspect this is really an area worth changing semantics in, the 
same way we changed the semantics for the defaults for "git pull". And I 
suspect it will confuse a lot fewer people, because fewer people depend on 
the default behaviour of "git push".

		Linus

Re: Problem with a push

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> IOW, the notion of "remote" refs really logically implies a mirror image, 
> exactly like you have it set up in your config: what is a local ref in one 
> repository is a remote ref in another. But that's not what the default 
> "git push" semantics are: it just matches refs directly, without that 
> mirroring.
>
> And the _reason_ for it doing that are obviously historical: we didn't use 
> to have the notion of "remotes", so back when I did that, it made sense. 
> It just doesn't make sense any more.

There are two aspects of this issue.  If "matching refs"
semantics makes sense, and if pushing refs/remotes makes sense.

I think the above description risks confusing new people by
sounding as if you are saying no to the former question.

"Pushing to the ref of the same path" makes _PERFECT_ sense even
today for a push into a bare repository used for publishing.

It only is not the right thing to do 50% of the time when you
are pushing into a live repository.

And I everyday use an example of why "matching refs" makes sense
for the other 50% of "push into a live repository" case.  When I
work on git.git, the second-from-final step every day is to push
into a live repository I have at k.org for final build in an
environment different from what I use for development.  I do
"matching refs" push, go there and "git reset --hard" to update
the working tree to build all four branches (there is the issue
that I am too lazy to install receive-pack hook in the live
repository to do that reset --hard to sync the working tree for
me, but that is a separate issue).

So it is not like "matching refs" is always wrong.  It is wrong
in some cases, and is perfectly good in some other cases.

What does not make sense AT ALL is to push what you keep under
refs/remotes/ to outside.  This issue actually has existed from
the very beginning, and we had a specific instruction that said
"remove 'refs/heads/origin' from your published repository
otherwise you will confuse yourself with push".  This was before
separate-remote layout was invented and refs/heads/origin was
the remote tracking branch for the 'master' at the other side.

Back when you did the original "send-pack", there was nothing
outside of refs/{heads,tags}, so historically it made sense to
say "ALL matching", but even then we had to be careful about
'heads/origin'.  Now it does not make sense anymore(I am saying
that not-renaming is OK but sending refs/remotes is Bad, which
is quite different from what you said).

Probably we should not do push anything other than refs/heads/
when we do "matching refs"

I think what we might want to do around this area are:

 - Don't change anything, if the command line says refspec, or
   the remote has push refspec specified.

 - When doing 'matching refs', do it only under refs/heads/.

 - Ship with a receive-pack hook that attempts a 3-way merge
   update when the currently checked out branch is updated.

Additionally we can give an option to "git clone" (or "git
remote add") to arrange the cross-push configuration for
mothership-satellite Andy showed in the clone's .git/config;
but I think that is a separate issue.

Re: Problem with a push

[Linus Torvalds]

On Tue, 12 Jun 2007, Junio C Hamano wrote:
> 
> I think what we might want to do around this area are:
> 
>  - Don't change anything, if the command line says refspec, or
>    the remote has push refspec specified.
> 
>  - When doing 'matching refs', do it only under refs/heads/.

I think these both are "obviously good".

>  - Ship with a receive-pack hook that attempts a 3-way merge
>    update when the currently checked out branch is updated.

Well, if it wasn't a fast-forward, then the user did a push with "git push 
-f", which implies _replacing_ the currently checked out branch.

So by three-way, I assume you mean the "git checkout -m" behaviour, and a 
fast-forward. What about a non-fast-forward (ie "git push -f"?) Should 
that imply "git checkout -f" semantics on the receiving side? That would 
kind of be sensible.

		Linus

Re: Problem with a push

[Alex R.M. Turner]

On Mon, 11 Jun 2007, Linus Torvalds wrote:

> 
> 
> On Mon, 11 Jun 2007, Alex R.M. Turner wrote:
> > 
> > Cool - that totally makes sense, HEAD is a link to master. so updating 
> > HEAD failed because it was already up to date.
> 
> Yes. Well, strictly speaking it failed because it _wasn't_ up-to-date 
> *before* the push (so "git push" thought it should update it), but it had 
> become up-to-date (through the symref link) by the time it was actually 
> its turn to be updated.
> 
> > The command was simply:
> > 
> > git push
> 
> Ok, as Junio points out, it's then just the fact that both repositories 
> had the same "remote" refs, and then the default of just updating 
> everything in common kicks in.
> 
> That default used to make sense back when, but it doesn't make sense for 
> remotes, since those are generally "local" to each repo.
> 
> > This repo was cloned from one on another server (the server I use to 
> > backup everything) with a git clone command:
> 
> Yeah. Normally you'd (well, _I_ would) only push to bare repositories, and 
> normally you wouldn't make those bare repositories have "remotes" entries, 
> which is why you're the first to apparently even notice this insanity.
> 
> It wasn't your fault, it's simply bad defaults for git behaviour.
> 
> The behaviour for "git pull" has improved _immensely_ over the last few 
> months, but "git push" still does the same thing it always did, because 
> fewer people care about pushing than pulling, and because the old "git 
> push" behaviour of just updating all the branches in common actually 
> happens to be the right thing when you do *not* make the central 
> repository contain remote branches of its own.
> 
> > Based on all this, what is the correct way to update my core repo on my 
> > server? (I'm sorry - I'm pretty new to git, so I haven't quite cottoned on 
> > to some aspects yet).
> 
> With the current git model, I would suggest:
> 
>  - for "central" repositories, use a bare repository, and don't create 
>    "remotes" branches in that central repository at all.
> 
>  - for other repositories, don't push into them, just _pull_ into them 
>    (because that also knows about updating the working tree etc: pushing 
>    is really meant to be done only into bare and central ones that don't 
>    actually have any work happening in them, and _cannot_ have any work 
>    happening in them because they don't even have a working directory 
>    associated with them)
> 
> That said, I don't think that's necessarily the right answer in the longer 
> run. It's how git people do things, but it's not necessarily the *best* 
> way of doing things. I think the better solution in the longer term is to 
> simply improve how "git push" works:
> 
>  - we should probably do the same kinds of .git/config file entries for 
>    pushing as we do for fetching, and just get rid of the old implicit 
>    model, and instead have a nice refspec pattern model for what gets 
>    pushed instead.
> 
>    I _think_ the refspec cleanup work by Daniel makes this something we 
>    can almost already do. Daniel?
> 
>  - we should also likely have some way to specify what happens when you 
>    push into a branch that is currently checked out and has a working tree 
>    associated with it.
> 
>    This was briefly discussed a few weeks ago, but nobody cared enough, I 
>    suspect.
> 
> anyway, I think the _proper_ thing to do would be to associate each 
> [remote] entry in the config file with a "push" refspec pattern, the way 
> we do for "fetch" already.
> 
>     Linux


Just so you don't think I'm completely crazy, I'll explained what caused 
this:

I first created a repo on machine B by initializing a blank repo, then 
fetching all historic revisions using git-svn from svn.  Then I cloned the 
repo to machine A using a git clone.  Once I had the clone on machine A, I 
initialized a new repo on machine B by doing a git clone from the repo on 
machine A, so that the remote branches would point to the right place so a 
git push would work.  I see now that that caused a problem because the 
repo on machine A now has remote branches pointing to machine B, which 
isn't right because that repo doesn't exist anymore.

Based on what you've said, it seems like I should be initialising a blank 
repo on machine A, then pushing from machine B to machine A, rather than 
cloning on A from B.

At this point would it just be sensible to delete the remote branches on 
machine A?

Alex

Re: Problem with a push

[Linus Torvalds]

On Tue, 12 Jun 2007, Alex R.M. Turner wrote:
> 
> Based on what you've said, it seems like I should be initialising a blank 
> repo on machine A, then pushing from machine B to machine A, rather than 
> cloning on A from B.

That's generally what you'd do for a central repo, yes.
But:

> At this point would it just be sensible to delete the remote branches on 
> machine A?

Yes, in the current environment, the easiest thing to do is to just remove 
those branches.

OR, alternatively, just keep them, but on machine B, make your .git/config 
file have something like

	[remote "origin"]
		url = ssh://aturner@svn.mintpixels.com/data/git/mls
		fetch = +refs/heads/*:refs/remotes/origin/*
		push = refs/heads/*:refs/heads/*

which should just make it clear to "git push" than when you push from B to 
"origin", you should push everything under "refs/heads" (assuming that's 
what you want, of course)-


		Linus

Re: Problem with a push

[Jon Loeliger]

On Mon, 2007-06-11 at 19:40, Linus Torvalds wrote:
> That said, I don't think that's necessarily the right answer in the longer 
> run. It's how git people do things, but it's not necessarily the *best* 
> way of doing things. I think the better solution in the longer term is to 
> simply improve how "git push" works:
> 
>  - we should probably do the same kinds of .git/config file entries for 
>    pushing as we do for fetching, and just get rid of the old implicit 
>    model, and instead have a nice refspec pattern model for what gets 
>    pushed instead.

Yeah, the other day I was baffled briefly by the fact that
I added a remote to my config using "git remote add ..."
with the intent of using it for pushing to a publishing site.
I forgot that it set up fetch only refs.

Maybe a new "--push" flag to 'git remote add --push ..."
to indicated the intended flow direction for a remote?

> anyway, I think the _proper_ thing to do would be to associate each 
> [remote] entry in the config file with a "push" refspec pattern, the way 
> we do for "fetch" already.

nod

jdl

Re: Problem with a push

[Martin Langhoff]

On 6/13/07, Junio C Hamano <gitster@pobox.com> wrote:
>  - When doing 'matching refs', do it only under refs/heads/.

Yes please ;-)

We've had this conversation about 2 weeks ago -- it's confusing (and
worrying) to see that a git-push tries to push stuff from remotes/ to
the repo...

cheers,

martin

[PATCH] "git-push $URL" without refspecs pushes only matching branches

[Junio C Hamano]

When "git push" is run without any refspec (neither on the
command line nor in the config), we used to push "matching refs"
in the sense that anything under refs/ hierarchy that exist on
both ends were updated.  This used to be a sane default for
publishing your repository to another back when we did not have
refs/remotes/ hierarchy, but it does not make much sense these
days.

This changes the semantics to push only "matching branches".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Junio C Hamano <gitster@pobox.com> writes:

 > Probably we should not do push anything other than refs/heads/
 > when we do "matching refs"
 >
 > I think what we might want to do around this area are:
 >
 >  - Don't change anything, if the command line says refspec, or
 >    the remote has push refspec specified.
 >
 >  - When doing 'matching refs', do it only under refs/heads/.
 >
 >  - Ship with a receive-pack hook that attempts a 3-way merge
 >    update when the currently checked out branch is updated.
 >
 > Additionally we can give an option to "git clone" (or "git
 > remote add") to arrange the cross-push configuration for
 > mothership-satellite Andy showed in the clone's .git/config;
 > but I think that is a separate issue.

 remote.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/remote.c b/remote.c
index 500ca4d..cf98a44 100644
--- a/remote.c
+++ b/remote.c
@@ -544,6 +544,13 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
 			if (!pat)
 				continue;
 		}
+		else if (prefixcmp(src->name, "refs/heads/"))
+			/*
+			 * "matching refs"; traditionally we pushed everything
+			 * including refs outside refs/heads/ hierarchy, but
+			 * that does not make much sense these days.
+			 */
+			continue;
 
 		if (pat) {
 			const char *dst_side = pat->dst ? pat->dst : pat->src;