Re: "git push" logic changed?

Greg KH <greg@kroah.com> writes:

> As of the git development tree from last night, 'git push' seems to work
> a bit differently now.

The change was 9e9b267.  I suspect the earlier way was a bit
more friendly to savvier people (especially the subsystem
maintainers and the project lead), but it was found to be
confusing for people who clone from an upstream and then use
that as a shared repository.  Their developers further clone
from that shared repository, and as needed pull from the true
upstream.  When they push their changes back, "git push
central:/shared.git/" would trigger a "remote origin does not
fast forward" error, depending on when these developers fetched
from the shared repository the last time, and whether they
stored what they fetched from the shared repository in their
"origin" or not.  If you do "git pull central:/shared.git/", not
"git pull origin" (taking advantage of remotes/origin file),
your "origin" branch would become out-of-date.  Which is OK for
the purpose of maintaining "master" branch properly, but pushing
meaningless "origin" back to "origin" at the shared repository
(which is also meaningless) was triggering an error and causing
confusion in that setup.

> Or should I always be doing --all?

In order to make sure all your local refs are on the "parent",
then yes.  And this is not new.  It used to push all the refs
that appear in _both_ your local repo and the "parent" repo, so
your new tags and branches did not get propagated so you needed
to use '--all' in such a case anyway.  We now also have '--tags'
to push all tags.

We could probably resurrect the earlier behaviour with a
'--matching' option or something if you'd like.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html