Johan Herland <jo...@herland.net> writes:
>> +static void setup_push_current(struct remote *remote, struct branch *branch)
>> +{
>> + if (!branch)
>> + die(_(message_detached_head_die), remote->name);
>> + add_refspec(branch->name);
>
> Here (and above) we add a refspec to tell Git exactly what to push
> from the local end, and into what on the remote end.
Correct.
> Is it possible to end up with multiple simultaneous refspecs
> matching the same local ref, but mapping to different remote refs?
Sorry, I don't follow. If you say "push.default = current" and you
do not give any other stronger clue (e.g. "git push origin master"
on the command line, or "git push [origin]" with remote.origin.push
configured), the above function is called and sets up your current
branch to be pushed to the same.
It is a bit more interesting for "push.default = upstream", which is
for centralized workflow. If you forked frotz and nitfol branches
both from their master, e.g.
$ git checkout -t -b frotz origin/master
$ git checkout -t -b nitfol origin/master
after having worked on one of the branches, when you want to push it
back, the result of working on the topic branch goes back to master,
but I think that is what you want in the centralized workflow. If
it fast-forwards, you are fine, and if it does not, you will fetch
your upstream, i.e. their master, integrate your work with it, and
then push it back. At that point, you are playing the role of the
integrator of the shared master branch, because what you do on your
topic branch when you integrate others' work from master is exactly
that---you are not perfecting the theme you wanted to achieve on
your topic branch, but are integrating that result into shared
master to advance the overall state of the project. So pushing the
result back to 'master' makes perfect sense. After that, when you
have to restart your work on the other branch, you may first "pull
--rebase" before continuing, or you may just keep going with your
work based on a tad old origin/master. But when you finish working
on that topic and are about to push it out, you would be doing the
same "tentatively don the central integrator's hat", and again it
makes sense to push the result to 'master'.
So in that sense, it is not "which one wins". It is more like "you
can push only after you become up to date, so there isn't one branch
overwriting the other one."
That is how I view it, anyway.
cf. http://git-blame.blogspot.com/2013/06/fun-with-various-workflows-1.html
>> +static int is_workflow_triagular(struct remote *remote)
>
> s/triagular/triangular/
Thanks.
>
>> +{
>> + struct remote *fetch_remote = remote_get(NULL);
>> + return (fetch_remote && fetch_remote != remote);
>
> This changed from a strcmp() to a pointer compare. That might be safe,
> depending on the sources of the two struct remote *, but I'm not sure.
Given the way remote_get() works, it should be correct, I think.
--
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
