Re: Please discuss: what "git push" should do when you do not say what to push?

If the conclusion of the discussion is that we will change the default,
the transition to the new default will go like this:

 1. An announcement message to let the user communities know about the
    future change will be distributed in a way similar to the previous
    request-for-discussion message was distributed.

 2. The first version of Git that is released after such an announcement
    will start issuing a warning when you type "git push" to send the
    matching branches to the default location unless you have configured
    push.default variable.  The users who want to keep the current default
    can do

	$ git config push.default matching

    and the users who want to use different settings can do one of:

	$ git config push.default current
	$ git config push.default upstream
	$ git config push.default nothing

    to silence this warning. The warning will be issued unless you do so,
    to help those who missed the message #1.

 3. We wait for a few release cycles.

 4. The default changes.  If you do not configure push.default variable,
    it no longer defaults to matching, but does something else (the choice
    among the three other alternatives will be decided in the discussion).
    The warning message will be reworded---instead of saying "will stop
    being the 'matching' in the future", it will say "has changed to X".

 5. We wait for a few release cycles.

 6. The warning is removed.

A typical release cycle lasts for 8-10 weeks.

On 17/03/12 05:22, Junio C Hamano wrote:

If the conclusion of the discussion is that we will change the default,
the transition to the new default will go like this:

 1. An announcement message to let the user communities know about the
    future change will be distributed in a way similar to the previous
    request-for-discussion message was distributed.

 2. The first version of Git that is released after such an announcement
    will start issuing a warning when you type "git push" to send the
    matching branches to the default location unless you have configured
    push.default variable.  The users who want to keep the current default
    can do

	$ git config push.default matching

    and the users who want to use different settings can do one of:

	$ git config push.default current
	$ git config push.default upstream
	$ git config push.default nothing

    to silence this warning. The warning will be issued unless you do so,
    to help those who missed the message #1.

 3. We wait for a few release cycles.

 4. The default changes.  If you do not configure push.default variable,
    it no longer defaults to matching, but does something else (the choice
    among the three other alternatives will be decided in the discussion).
    The warning message will be reworded---instead of saying "will stop
    being the 'matching' in the future", it will say "has changed to X".

 5. We wait for a few release cycles.

 6. The warning is removed.

A typical release cycle lasts for 8-10 weeks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Unfortunately, "a few release cycles" strikes me as a rather hopeful
description.  For example, a user installing the new Ubuntu LTS release
(due out next month) would feel completely justified in not upgrading
until 2017, whereas the rest of us would get rather bored disabling the
same old warning in every new repo we create for the next five years.

Could I suggest when a user inits/clones a new repository using a
post-change version of git, we do an automatic `git config
push.warned_about_default_change true`, then warn forevermore when users
push from a repo with neither that option nor a push.default?  This will
warn existing users with arbitrarily long upgrade cycles, and reduce the
amount of noise during the (necessarily) already noisy first days of a
new repo.

FWIW, I've been stung by the old behaviour and think the change of
default is a great idea, but have nothing more useful to add :)

	- Andrew

On Sat, Mar 17, 2012 at 1:22 AM, Junio C Hamano [off-list ref] wrote:

If the conclusion of the discussion is that we will change the default,
the transition to the new default will go like this:

I am in general agreement with the course of action outlined. There is
one little thing I had expected in addition, that is not discussed:

 --force should change behaviour, immediately, to "current" or even
none (forcing the user to name the remote and branch explicitly).

The potential for messups with --force combined with "matching" and a
repo that allows it is considerable. And I cannot imagine any
mainstream use cases for --force defaulting to matching; at least none
important enough to counterbalance the damage.

cheers,


m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

Martin Langhoff [off-list ref] writes:

On Sat, Mar 17, 2012 at 1:22 AM, Junio C Hamano [off-list ref] wrote:

quoted

If the conclusion of the discussion is that we will change the default,
the transition to the new default will go like this:

I am in general agreement with the course of action outlined. There is
one little thing I had expected in addition, that is not discussed:

 --force should change behaviour, immediately, to "current" or even
none (forcing the user to name the remote and branch explicitly).

The potential for messups with --force combined with "matching" and a
repo that allows it is considerable. And I cannot imagine any
mainstream use cases for --force defaulting to matching; at least none
important enough to counterbalance the damage.

Well, one can always use

  git push <remote> +:

instead of

  git push --force

for "matching" push... but I think you would have to provide name of
repository.

-- 
Jakub Narebski

By now it should be obvious that most people would prefer to see the
default behaviour for 'git push' to be something other than matching, even
if you did not read each and every "me too" message.

Actually, we've known it from the beginning. Otherwise, we wouldn't have
made noises about it in the first place ;-).  It was not the primary
objective of the discussion thread to decide if we are going to switch
away from 'matching' by voting (waking up those who are sleeping, so that
they do not have to be surprised with "I didn't know that was happening!"
was).

The new default we are switching to is not about how many people prefer it
for their own use. It is about what default is the least confusing to the
new users.  A default whose behaviour is easy to explain, easy to follow
and easy to understand is the goal. Once people understand what they want
and realize they fall into a minority, it is easy for them to configure
their push.default to something else, like 'matching'. And 'matching' was
a bad default for that purpose; it was the hardest to explain and
understand in the context of the workflows of many new people.

Many people said that they like 'upstream' solely based on their personal
preference, but a few people did justify their preference of 'upstream'
over 'current' based on their experience in teaching new people and
observing the sharp edges that hurt them. And they all sounded reasonable.

In order to show how the world after phase #2 of the transition [*1*]
would look like to developers, testers and early adopters, I am planning
merge Matthieu's patch mm/push-default-switch-warning topic [*2*] to
'next', together with Christopher's ct/advise-push-default topic [*3*];
hopefully these topics can be merged to 'master' soon after 1.7.10 final.

Thanks.

To people who helped spreading the initial RFD message: please do feel
free to distribute this message to the same channels, too.


[References]

*1* http://article.gmane.org/gmane.comp.version-control.git/193308

*2* https://github.com/gitster/git/commit/5293b54

*3* https://github.com/gitster/git/commit/f25950f