On Thu, May 16, 2013 at 3:21 AM, Ramkumar Ramachandra
<artag...@gmail.com> wrote:
> Felipe Contreras wrote:
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>> pushremote = github
>> push = refs/heads/master
>
> Hm. Some thoughts:
>
> fetch and push aren't symmetric. By default fetches are batched: when
> you say 'git fetch', it fetches all the refs and uses the
> remote.<name>.fetch refspec to update the refs on your side. Now, I
> would argue that this is the correct design, because I rarely want to
> fetch just one ref (and that is broken, by the way: refs on my side
> aren't updated for some weird reason). The other reason this is
> correct is because fetching has nothing to do with local branches: how
> you _merge_ your remote branches to your local branches is entirely
> orthogonal to the issue (and that is controlled by
> branch.<name>.merge).
>
> Now, push is a different ball game altogether. There are people who
> do batched pushes (push.default = matching has been the default for 8
> years now).
And is going to change soon.
> However, the support for a batched push in a triangular
> workflow is very limited: I can't say git push master hot-branch
> pickaxe-doc, and expect them to go to the right remotes (this idea has
> already been discussed and rejected). Back to your patch: if you want
> to support batched pushes to map refs correctly, you should write a
> patch for remote.<name>.push. It has a very valid usecase too: there
> are people who use Gerrit and they shouldn't have to do git push
> <name>:refs/for/<name> every single time. Neither should they have to
> configure each branch.<name>.push. The ref-mapping is an inherent
> property of the remote, not of the local branch. And
> branch.<name>.merge is entirely orthogonal to ref-mapping, as I
> already explained.
>
> That said, I think the concept of a downstream can be useful. I have
> branch.hot-branch.remote set to origin, and
> branch.hot-branch.pushremote set to ram. Now, I push some changes: my
> prompt still says > (indicating unpushed changes), and this is very
> annoying. I would definitely like git to be able to recognize that
> I'm ahead of upstream, but in-sync with my downstream. So, your
> branch.<name>.push should probably be named
> branch.<name>.downstreamref and be used only for informational
> purposes (@{d} and git status)?
That makes absolutely no sense.
[branch "master"]
remote = origin
merge = refs/heads/master
pushremote = github
downstreamref = refs/heads/whaaa:refs/heads/master
What is the point of 'refs/heads/whaaa'?
> Wait, why do we need it at all? Is
> there something that we cannot infer from a proposed
> remote.<name>.push? Why will we ever need to override that refspec
> mapping with a local branch configuration?
[branch "master"]
remote = origin
merge = refs/heads/master
pushremote = github
push = refs/heads/fc/master
[branch "fc/old-remote/hg"]
remote = .
merge = refs/heads/master
pushremote = github
push = refs/heads/fc/remote/hg
Tell me how you express that without 'remote.branch.push'.
Cheers.
--
Felipe Contreras
--
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
