Re: Problem with a push

> 
> 
> 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