Re: pull/push inconsistencies

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: May 16, 2007, 01:11 UTC
Message-ID: <46a038f90705151811o2159aa5ai84a13e77e790e376@mail.gmail.com>
In-Reply-To: <7vtzudhayr.fsf@assigned-by-dhcp.cox.net>

On 5/16/07, Junio C Hamano <junkio@cox.net> wrote:

Show 9 quoted lines

> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
> > When tracking several branches from a repo, git-pull does a fetch (of
> > all the remote heads) and merges _only the tracking branch currently
> > checked out_. That's ok. However, if I checkout another tracking
> > branch and issue git-pull, the merge does not happen because git-fetch
> > finds nothing new on the remote side. git-pull should merge anyway if
> > remotes/origin/<trackinghead> is ahead of the local head.
>
> That's my expectation and I am a bit surprised if it doesn't.

I'll try get a repro script then.

Show 6 quoted lines

> > My second issue is that git-push does not update
> > remotes/<repo>/<headname> so if I do git-push && gitk --all it looks
> > as if I haven't pushed. Misleading again. :-/
>
> The standard answer is not to push into a live repository
> without understanding what you are doing.

I don't quite understand that statement. I think I know what I am doing: telling git-push to push new commits from matching local refs to remote refs safely (only ff, unless there's a + in the configuration for that head).

Why can't git match that the remote is the remote in .git/refs/remotes and put the right data SHA1 in .git/refs/remotes/<headname>?

...

> And pushing into live repository using 'matching refs' is almost
> always a mistake, unless the user knows what he is doing.

Hey - I'm only using it because you've recommended it as a migration path! ;-) Combined with tracking branches, it works great.

Show 22 quoted lines

> > Third issue - if I do
> >
> >  # we start with a cloned repo that is in sync with
> >  # its "origin" repo. No local commits to speak of...
> >  # git-fetch brings updates to 3 remote branches - none affecting the current
> >  # checked out branch...
> >   git-fetch
> >   git-commit some/path
> >   git-push
> >
> > the output of git-push will show _4_ branches being pushed. For some
> > reason git-push says that it's pushing remotes/origin/branchname ->
> > origin/branchname for all the branches fetched recently -- and not
> > modified! I expect only _1_ branch to be named during push - the only
> > one.
>
> git-push without parameters and configuration pushes matching
> branches.  This has been true from day one.  Again, I think we
> should be able to make this safer so that "git-push" in cloned
> repository would do something more restricted (perhaps limiting
> to refs/heads?), but I do not think of a universally acceptable
> canned configuration.

There are 2 things that I see as wrong...
 - local .git/refs/remote/origin/foo and refs/heads/foo match - why is
git-push talking about updating them?
 - matching refs should ignore .git/refs/remote

But perhaps I'm naive in thinking that the 'matching refs' thing will ignore the local .git/refs/remotes directory. AFAICS it's the only sane thing to do.

cheers,

martin