Re: "git push" logic changed?

Greg KH <greg@kroah.com> writes:

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.

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.