From: Andrew Sayers <andrew-git@pileofstuff.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Please discuss: what "git push" should do when you do not say what to push?
Date: Sat, 17 Mar 2012 10:05:11 +0000 [thread overview]
Message-ID: <4F6461D7.40303@pileofstuff.org> (raw)
In-Reply-To: <7vty1ndcoi.fsf@alter.siamese.dyndns.org>
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
next prev parent reply other threads:[~2012-03-17 10:05 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-17 5:10 Please discuss: what "git push" should do when you do not say what to push? Junio C Hamano
2012-03-17 5:22 ` Junio C Hamano
2012-03-17 10:05 ` Andrew Sayers [this message]
2012-03-18 18:50 ` Junio C Hamano
2012-03-18 21:26 ` Ævar Arnfjörð Bjarmason
2012-03-19 0:29 ` Junio C Hamano
2012-03-19 7:29 ` Sebastien Douche
2012-03-19 20:11 ` Andrew Sayers
2012-03-19 21:43 ` Junio C Hamano
2012-03-19 22:20 ` demerphq
2012-03-19 22:38 ` Junio C Hamano
2012-03-20 10:00 ` Andreas Ericsson
2012-03-19 22:47 ` Andrew Sayers
2012-03-19 22:59 ` Junio C Hamano
2012-03-20 21:20 ` Andrew Sayers
2012-03-20 23:09 ` Junio C Hamano
2012-03-20 23:41 ` Andrew Sayers
2012-03-21 0:25 ` Junio C Hamano
2012-03-20 14:12 ` Martin Langhoff
2012-03-20 15:28 ` Junio C Hamano
2012-03-20 18:31 ` Martin Langhoff
2012-03-20 16:43 ` Jakub Narebski
2012-03-21 17:54 ` Summary of discussion on "git push" default change Junio C Hamano
2012-03-21 18:05 ` Matthieu Moy
2012-03-17 14:00 ` Please discuss: what "git push" should do when you do not say what to push? Joey Hess
2012-03-19 0:36 ` Junio C Hamano
2012-03-17 18:43 ` fREW Schmidt
2012-03-18 4:02 ` H. Peter Anvin
2012-03-18 5:43 ` Marcus D. Hanwell
2012-03-18 16:52 ` Sebastian Schuberth
2012-03-19 9:07 ` Peter Krefting
2012-03-19 9:35 ` Letting remote repositories override local configuration Jonathan Nieder
2012-03-19 12:21 ` Peter Krefting
2012-03-19 18:57 ` Please discuss: what "git push" should do when you do not say what to push? Kevin Ballard
2012-03-20 2:27 ` Antony Male
2012-03-20 12:04 ` Jakub Narebski
2012-03-20 13:04 ` Antony Male
2012-03-20 7:13 ` Nathan Gray
2012-03-20 12:00 ` Ben Tebulin
2012-03-20 12:00 ` Ben Tebulin
2012-03-20 12:00 ` Ben Tebulin
2012-03-20 12:01 ` Ben Tebulin
2012-03-20 12:36 ` Filipe Fernandes
-- strict thread matches above, loose matches on Subject: below --
2012-03-19 18:26 Michael K. Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F6461D7.40303@pileofstuff.org \
--to=andrew-git@pileofstuff.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).