Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > The publish branch is the branch the user wants to push to, akin to the > upstream branch, which is the branch the user wants to use as a > baseline. It overrides other configurations, such as push.default, and > remote.<name>.push. > > The upstream branch is: > > branch.$name.remote > branch.$name.merge These two configuration variables are *NOT* the "upstream branch"; it is more like "the upstream branch of $name is _defined_ with these two variables". For example, with: [remote "foo"] fetch = refs/heads/*:refs/remotes/foo/* [branch "bar"] remote = foo merge = baz The upstream branch of 'bar' is refs/remotes/foo/baz, and that is determined by consulting these two variables, branch.bar.remote and branch.bar.merge to learn that we look at refs/heads/baz from foo and also refs/remotes/foo/baz is where we keep a copy of that. > The publish branch is: > > branch.$name.pushremote > branch.$name.push Can you give a description for "the publish branch for $name" here in a way similar to "the upstream" I gave an example above, so that anybody reading this log message can answer questions like... When the end users say master@{publish}, what conceptually are they naming? Can they use master@{publish} in a way similar to: $ git log master@{upstream}..master that gives us what we did since we forked, because master@{upstream} names the remote-tracking branch we locally have for the branch our 'master' integrates with? Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html