Jeff King wrote:
> 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.
It's a pretty typical triangular workflow, with a touch of fork maintainership.
Here are some types of branches I have:
* master [origin/master, gh/master] Git 1.9.1
My main master branch, I use it as a base point for many other branches. I
don't use origin/master because that's a moving target.
* dev/remote/hg-extra [master] remote-hg: store extra hg information in notes
A development branch. I don't publish those, therefore no @{publish}.
* fc/publish [fc/branch/nice-verbose, gh/fc/publish] sha1_name: add support for
@{publish} marks
A branch that is all good. I publish those, and use them for git-fc (my fork).
I think they should be in Git's core, but haven't been merged for some reason
or another.
Notice that the upstream branch is another local branch, not master. Strictly
speaking it's not an "upstream" branch, but I want 'git rebase' to use that as
the base point. Another @{base} concept might be more appropriate, but those
patches are a different story.
* up/publish [master] sha1_name: add support for @{publish} marks
A branch that should be sent upstream. I don't publish those.
Notice up/publish is different from fc/publish because the later depends on
another fc/* branch, which wasn't accepted upstream.
* fc/master [gh/fc/master] prompt: fix missing file errors in zsh
My main branch, used for git-fc. I merge Git's master, and cherry-pick various
fixes, so it has always the latest and greatest stuff.
Notice that 'gh/fc/master' is the publish branch, there is no upstream.
* pu [] Merge branch 'travis-ci' into pu
Similar to Junio's pu, I use `git reintegrate` to generate this branch using
'master' as the baseline, and merging all the fc/* branches. The result should
be identical to fc/master, if not, we are missing something from upstream, or
there's something missing in the fc/* branches.
It's not published, and has no upstream.
As you can see; some branches are published, others are not. The ones that are
not published don't have a @{publish}, and `git branch -v` doesn't show them.
Why is that hard to understand?
--
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
