Felipe Contreras <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
