On Fri, Apr 11, 2014 at 12:24:35PM -0700, Junio C Hamano wrote:

> > But the branch.master.push setting does not do
> > anything to "git push".
> I am not sure I understand this.  I thought that the desire behind
> the branch.*.push is to allow something like:
>       ... other things in the config ...
>       [remote]
>               pushdefault = foo
>       [remote "foo"]
>               url = ...
>               push = +refs/heads/*:refs/remotes/satellite/*
>                 fetch = +refs/heads/*:refs/remotes/foo/*
>       [branch "master"]
>               ; pushremote = foo
>               push = refs/heads/bar
> so that "git push" on 'master' will override the more generic "all
> local branches here will go to their remote-tracking hierarchy for
> this satellite" refspec.  And in that sense branch.master.push would
> do something to "git push".

Ah, I see. If I set "push.default" to "upstream", then the config I
showed before _does_ affect "git push". But I do not usually do that. I
have push.default set to "current", and sometimes override it using push
refspecs on certain repositories.

And that is why I find branch.*.push and Felipe's @{publish} useless for
my workflow. Pushes already go where I want them to, and I just want a
way to ask git to perform that config resolution for me. Whereas
Felipe's workflow is (I think) something like:

  # make a new branch...
  git checkout -b topic origin/master

  # now publish our branch, and remember our publishing point
  git push -p my-repo topic

  # and now further pushes automatically go to my-repo/topic
  git push

I can see there is some value in that override if you do things like:

  git push -p my-repo topic:some-other-name

because the "-p" means "remember this other name I gave".

I would think in such a workflow that most of your branches would end up
with publish config, though. And therefore @{publish} would become
equivalent to "where you would push". But Felipe indicated that he would
not want "branch -vv" to match where all branches would be pushed, but
rather only those that were specifically configured. So maybe I do not
understand his workflow after all.

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