Junio C Hamano wrote:
>         [remote "origin"]
>                 url = ... where Ram fetches and pulls from ...
>                 pushurl = ... where Ram pushes to ...
>                 fetch = refs/heads/*:refs/remotes/*
>                 updateTrackOnPush = no
> Then "git fetch" (or "git pull") will update the remote tracking
> branches Ram fetches from, and once his topic is finished, he can
> push to his publishing location, which won't touch the remote
> tracking branches used to keep track of the place he fetches from.

A "push" should never touch remote/refs/origin/* if there is a pushurl
configured.  Otherwise, it should.  I want my push to affect my
status.  The configuration variable makes no sense and should not

Unfortunately, pushurl doesn't get the same privileges as url even
though they're equal remotes.  How is my fork "inferior" to the
upstream project in any way?  A lot of us might be working on this
fork, and we will need something corresponding to refs/remotes/* to
inspect its state.  Like I said earlier, I think pushurl has a very
limited usecase: when the two URLs are actually mirrors (there is
really no fork; we're back in a centralized environment).  In fact, I
think it should be deprecated, because it interferes with my more
general approach.

Let's see what happens if we have two actual remotes.
remote/refs/origin/* will be updated when I fetch from, and push to,
origin.   remote/refs/ram/* will be updated when I fetch from, and
push to, ram.  It's very simple, and I don't need this complex rule of
when to update refs.  We should have a way to pair remotes together as
upstream/ downstream in the future.  Maybe even have a hierarchy of
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to