Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 16, 2013, 09:05 UTC
Message-ID: <CAMP44s3fPsGW_9aBbcsu8cJAagz8JEWV2HM=XRH3Rw4=SXdL7Q@mail.gmail.com>
In-Reply-To: <CALkWK0nTS6Vh7GfnrLWAK5VeevQyGN5N7xT43c+uqBQ5oM5tww@mail.gmail.com>

On Thu, May 16, 2013 at 3:21 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 23 quoted lines

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

Show 22 quoted lines

> 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