Re: What's in git.git (stable)

From: Junio C Hamano <junkio@cox.net>
Date: Dec 22, 2006, 21:49 UTC
Message-ID: <7v3b77y52j.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200612222156.21215.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 17 quoted lines

> Junio C Hamano wrote:
> ...
>>>> Possibilities:
>>>> 
>>>>  (1) Forget about that "protection" business.  If you do not
>>>>      want mistakes, use 'branch.*.merge' but otherwise we will
>>>>      continue to follow the good old "first set of branches"
>>>>      rule.
>>>
>>> What about marking default branch to merge explicitely using
>>> "Merge:" in remotes/<repo>, or remote.<name>.merge?
>> 
>> Sorry, how is that an improvement over the current branch.*.merge?
>> and how would that help not breaking existing setups?
>
> I meant that in addition to forgetting about "protection" business.
> This would be intermediate improvement over old behavior.

I do not think so. It does not talk about "when on my local branch X do this", and applies to all pulls from the named remote. Then longstanding rule of merging the first set of branches is just fine and as expressive. You see them the first in the list, and you already know they somehow matter more.

On the other hand, I think Santi's branch.*.merge (done in commit 5372806a) _was_ a real improvement.

> Perhaps make "protection" business optional, default to on for
> new users?

Now the question is how you would tell "new users".

The possibility (2) is not even good enough, because even old timers work in a newly cloned repositories.