From: "Philip Oakley" <philipoakley@iee.org>
To: <git@vger.kernel.org>
Cc: "Marat Radchenko" <marat@slonopotamus.org>,
"Felipe Contreras" <felipe.contreras@gmail.com>,
"Junio C Hamano" <gitster@pobox.com>,
"Marc Branchaud" <marcnarc@xiplink.com>
Subject: Re: Pull is Evil
Date: Thu, 1 May 2014 22:06:17 +0100 [thread overview]
Message-ID: <E699B6CE8ADD46618D52F05DB8EF6F07@PhilipOakley> (raw)
In-Reply-To: 536152D3.5050107@xiplink.com
From: "Marc Branchaud" <marcnarc@xiplink.com>
Sent: Wednesday, April 30, 2014 8:45 PM
[...]
> I don't think we'll ever be able to create a One "Git Pull" To Rule
> Them All.
> At best we'll end up with something with enough knobs that it could be
> configured to work in most workflows (I think we're actually pretty
> close to
> that). But for new users that defeats the purpose. It means that
> "git pull"
> is really an advanced command, and beginners should avoid it until
> they
> understand enough of git to configure it properly.
>
> So rather than perpetuate the myth that one command can always (or
> even just
> usually) do the right thing, let's just retire the command.
>
> All that said, I don't object to any attempts at improving the command
> either. But I also don't see any kind of improvement that would lead
> me to
> start using "git pull" let alone recommending it to new users.
>
> M.
>
> [1] By "significant" I mean "enough to perpetually create new mailing
> list
> threads about changing 'git pull'".
>
[general reply to all, rather than to anyone in particular, using Marc's
summary]
The point that there is no easy solution to an updated default pull
action that is right for everybody, straight out of the box, I think is
now fairly obvious, a summarised by Marc. I certainly avoid pull.
My 'solution', if it could be called that, would be that at the point of
switch over, after a period of release note warning and then code
warning, that the plain 'git pull' would not even do the no-ff, but
would simply refuse to do anything unless the user had explicitly set
the [new] config variable(s) to a value of _their_ choice. The message
could give guidance based on their old setting(s) and the new options as
appropriate, i.e. if they have an old definitive setting then the new
setting may be an obvious one.
During the warning period between the release cycles, we may have a two
step ramp up of the warning, where the first cycle allows users who have
read the release notes to choose their new setting and it's auto
detected from there on, then in the second cycle Git detects the lack of
a setting and gives a warning prompt (just like the Git 2.0 warning),
and finally the change over release makes a 'git pull' without a config
setting an error.
I know that for some it's a phaff that appears to waste time (been
there, been that person), but it does allow the stragglers time to pick
up the hints and not be too surprised, which will include many otherwise
professional folks who just happen to have other priorities [e.g. this
message typed from a Win XP machine!].
The approach does have a solid heritage, and avoids anyone (on the
coding side) having to decide on an initial default, when it should be a
user choice. Though I do agree with Filipe that the '--no-ff merge'
would probably be the least worst for the new user and likely be a
suitable 'if you don't know use this one' suggestion.
Philip
--
next prev parent reply other threads:[~2014-05-01 21:06 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-28 6:29 A failing attempt to use Git in a centralized environment Marat Radchenko
2014-04-28 18:41 ` Junio C Hamano
2014-04-30 14:21 ` Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment) Marc Branchaud
2014-04-30 14:55 ` Junio C Hamano
2014-04-30 19:45 ` Pull is Evil Marc Branchaud
2014-04-30 20:01 ` Jonathan Nieder
2014-04-30 20:01 ` Junio C Hamano
2014-04-30 21:48 ` Marc Branchaud
2014-05-02 7:40 ` Andreas Krey
2014-05-02 8:46 ` David Kastrup
2014-05-03 6:17 ` Andreas Krey
2014-05-03 6:55 ` David Kastrup
2014-04-30 20:14 ` Felipe Contreras
2014-04-30 22:06 ` Marc Branchaud
2014-04-30 22:25 ` Felipe Contreras
2014-05-01 9:46 ` brian m. carlson
2014-05-01 10:48 ` Felipe Contreras
2014-05-01 15:16 ` Junio C Hamano
2014-05-01 19:16 ` Felipe Contreras
2014-05-01 19:48 ` W. Trevor King
2014-05-01 20:07 ` W. Trevor King
2014-05-01 23:25 ` Felipe Contreras
2014-05-02 0:02 ` W. Trevor King
2014-05-02 0:37 ` Felipe Contreras
2014-05-02 1:10 ` W. Trevor King
2014-05-02 1:14 ` Felipe Contreras
2014-05-02 14:54 ` W. Trevor King
2014-05-02 18:55 ` Felipe Contreras
2014-05-02 19:07 ` W. Trevor King
2014-05-02 19:10 ` David Kastrup
2014-05-02 19:13 ` Felipe Contreras
2014-05-02 19:46 ` W. Trevor King
2014-05-02 20:34 ` Felipe Contreras
2014-05-02 21:13 ` W. Trevor King
2014-05-02 21:18 ` Felipe Contreras
2014-05-02 22:01 ` pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil) W. Trevor King
2014-05-02 22:20 ` Felipe Contreras
2014-05-03 0:05 ` pull.prompt or other way to slow/disable 'git pull' W. Trevor King
2014-05-03 9:50 ` Felipe Contreras
2014-05-04 18:51 ` W. Trevor King
2014-05-04 20:54 ` Felipe Contreras
2014-05-01 23:20 ` Re: Pull is Evil Felipe Contreras
2014-05-01 15:20 ` Marc Branchaud
2014-05-01 17:56 ` W. Trevor King
2014-05-01 18:04 ` Marc Branchaud
2014-05-01 18:30 ` W. Trevor King
2014-05-01 20:21 ` Marc Branchaud
2014-05-01 23:28 ` Felipe Contreras
2014-05-02 7:16 ` Andreas Krey
2014-05-02 8:14 ` Felipe Contreras
2014-05-02 19:29 ` Junio C Hamano
2014-05-02 19:53 ` Junio C Hamano
2014-05-01 23:45 ` brian m. carlson
2014-05-01 23:39 ` Felipe Contreras
2014-05-01 19:22 ` Felipe Contreras
2014-05-01 19:43 ` Marc Branchaud
2014-05-01 19:27 ` Felipe Contreras
2014-05-01 21:06 ` Philip Oakley [this message]
2014-05-01 21:16 ` Philip Oakley
2014-05-01 23:34 ` Felipe Contreras
2014-05-01 23:59 ` W. Trevor King
2014-05-02 0:31 ` Felipe Contreras
2014-04-30 16:47 ` Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment) Felipe Contreras
2014-04-30 17:09 ` Pull is Evil Matthieu Moy
2014-04-30 18:31 ` Felipe Contreras
2014-04-30 19:10 ` Junio C Hamano
2014-04-30 19:32 ` Felipe Contreras
2014-04-30 19:53 ` Junio C Hamano
2014-04-30 20:11 ` Felipe Contreras
2014-04-30 16:12 ` A failing attempt to use Git in a centralized environment Stepan Kasal
2014-04-30 17:15 ` Geert Bosch
2014-05-04 8:58 ` John Szakmeister
2014-05-02 20:56 ` Max Kirillov
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=E699B6CE8ADD46618D52F05DB8EF6F07@PhilipOakley \
--to=philipoakley@iee.org \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=marat@slonopotamus.org \
--cc=marcnarc@xiplink.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.