Re: "git push" logic changed?

On Fri, Jan 20, 2006 at 04:03:50PM -0800, Junio C Hamano wrote:
> 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.

Well what should I do then to push to "orgin"?
	$ git push
	Where would you want to push today?
	Usage: /home/greg/bin/git-push [--all] [--tags] [--force] <repository> [<refspec>...]

	$ git push origin
	No refs given to be pushed.

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

Yes, but "git push origin" used to push my local changes there, and
that's all I really want.

Someone off-list told me I could edit my .git/branches/parent file to
fix this issue for that branch.  Since I hand-created that file in the
first place, that's not a bit deal.  But I was relying on git to get the
"origin" branch right, as I didn't edit it at all :)

So, what I'm really just looking for is a simple way to push back to the
repository that I cloned this one from, as I only have one "repo" here.

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

It would be nicer not to break a previously working command :)

Or at least show me how to change it so I can just easily push back to
where I cloned the original from...

thanks,

greg k-h

-
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