Re: [PATCH 3/6] push: change `simple` to accommodate triangular workflows

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2013, 07:43 UTC
Message-ID: <7v38s8dkd8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALKQrgfAT9GhD-_tZHr9wRA6R6g7ttDWTsmUQXdWUhG-gwNBqQ@mail.gmail.com>

Johan Herland <johan@herland.net> writes:

Show 8 quoted lines

>> +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.

Show 7 quoted lines

>
>> +{
>> +       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.