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

From: Junio C Hamano <junkio@cox.net>
Date: Dec 22, 2006, 20:13 UTC
Message-ID: <7virg3zo1k.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0612221949490.19693@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 9 quoted lines

> HOWEVER, it has been in "What's cooking in git (topics)".
>
> Having said that, we could (at least for some time) print a big red 
> warning for the specific case of "git pull" meaning "git pull origin 
> <whateveristhefirstfetchedhead>" that this will GO AWAY SOON.
>
> Of course, you would not see it. Only your script.
>
> BTW I would _never_ allow a script to rely on such a DWIM feature.

That's too strong a statement. It is not DWIM but has been a longstanding rule to use "the first set of branches" for the merge. We've merged the first set of branches since day one, and even after branch.*.merge we've done so unless you do not have such configuration.

The complaint (or "newbie protection") was a backward incompatible change, and it was executed poorly. So my apologies go to Merlyn.

While many "new features" can be done in backward compatible way, any "newbie protection" can break existing practices -- because the whole point of "protection" is to forbid what once was allowed only because we did not use to check. And when we have something that we check now that we did not check before, that by definition will not be backward compatible.

Some backward incompatibilities are more justfiable than others. For example, we recently changed "git add" without argument not to do anything. It used to have the same effect as "git add .", but (1) adding all files in a working tree is a rare event, (2) just a single dot is not hard to type, (3) without argument you will get a response "not doing anything". On the other hand, doing "git add" without argument by mistake and ending up with the index with many unwanted files is more painful and more likely to hapen -- it is more valuable to protect users against it than saving the two keysrokes. That's why I think that change is a justified improvement.

I do not think this "merge complaint", at least in the form that lived on 'master', is justifiable. The first one that was merged from the topic made it a requirement to have the branch.*.merge configuration when you do not give explicit refspecs on the command line, which was just outright WRONG. The one currently on the public repository says if the fetch ended up getting only one branch then not having branch.*.merge is Ok, which arguably is an improvement, but I do not think is good enough. I mentioned other possibilities in my earlier message.

I also personally think that it is not as clear cut as the "git add" case that "the first set of branches" rule is wrong, but the trouble I caused to Merlyn and Luben primarily comes from the check to trigger "newbie protection", not from what the protection is trying to do.