From: Marc Branchaud <hidden> Date: 2016-06-15 23:00:58
(Apologies for not CCing all the folks who've participated in the "Pull is
Evil" thread -- I couldn't find a good branch of that thread for this message.)
OK, so maybe "git pull" is just Mostly Evil. People seem to have found many
different ways to make it work for them.
But in reality "git pull" has become a chimera that confuses a large number
of new users, and that experienced users either avoid entirely or customize
to give them a convenient shorthand for working in their particular
environment. As a tool for new git users, it just doesn't seem to be
achieving its goals.
I think the git project as a whole would benefit if it started to treat "git
pull" as an advanced command, in the sense that it needs to be configured by
an experienced user in order to make it correctly follow a project's
workflow. Once it's configured properly, "git pull" is a powerful tool that
gives users an easy way to do complex things. In that sense, it may be
appropriate for a project to tailor "git pull" as it likes, then teach its
own users to use the command.
However, when it comes to teaching people how to use git qua git, "git pull"
should be the last thing they learn about, because it's only after you
understand various basic git concepts that you can configure "git pull" to do
the right thing.
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it hasn't
been configured, and that the user should run "git help pull" for guidance.
It'll take quite a bit of time, but I think that if we change our attitude
towards "git pull" and take this unconfigured-by-default approach, then in a
few years the entire git ecosystem will be in a better place.
M.
From: David Kastrup <hidden> Date: 2016-06-15 23:00:58
Marc Branchaud [off-list ref] writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't been configured, and that the user should run "git help pull"
for guidance.
Fetching is uncontentious, and I _think_ that fast-forwards are pretty
uncontentious as well.
It's just when the merge-left/merge-right/rebase-left/rebase-right
decision kicks in that prescribing one git-pull behavior looks like a
recipe for trouble.
--
David Kastrup
From: Philip Oakley <hidden> Date: 2016-06-15 23:00:58
From: "David Kastrup" <redacted>
Marc Branchaud [off-list ref] writes:
quoted
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't been configured, and that the user should run "git help pull"
for guidance.
Fetching is uncontentious, and I _think_ that fast-forwards are pretty
uncontentious as well.
While the fast forward is /pretty/ uncontentious, it still maybe
contentious for some. But more importantly (in my mind) is the fact that
it (git pull) hasn't been configured, and pressing for _that_ to happen
is the big benefit.
I'm more than happy that the fast-forward should be the recommended 'if
you don't know, choose this' option, as you say, its pretty
uncontentious and has easy mechanisms for backing out which are well
illustrated across the internet.
It would still need a few cycles of ramping up the warnings to ease folk
in gently. One has to beware of the issues at both ends of the Kruger
Dunning curve. This thread discussion in some ways has suffered from the
inverse K-D effect.
It's just when the merge-left/merge-right/rebase-left/rebase-right
decision kicks in that prescribing one git-pull behavior looks like a
recipe for trouble.
--
David Kastrup
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:58
Philip Oakley wrote:
From: "David Kastrup" <redacted>
quoted
Marc Branchaud [off-list ref] writes:
quoted
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't been configured, and that the user should run "git help pull"
for guidance.
Fetching is uncontentious, and I _think_ that fast-forwards are pretty
uncontentious as well.
While the fast forward is /pretty/ uncontentious, it still maybe
contentious for some.
So? No defaults can please absolutely everyone, the best anybody can do
is try to please the majority of people, and merging fast-forwards only
does that.
--
Felipe Contreras
From: David Lang <hidden> Date: 2016-06-15 23:00:58
On Fri, 2 May 2014, David Kastrup wrote:
Date: Fri, 02 May 2014 17:45:23 +0200
From: David Kastrup <redacted>
To: git@vger.kernel.org
Subject: Re: Pull is Mostly Evil
Marc Branchaud [off-list ref] writes:
quoted
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't been configured, and that the user should run "git help pull"
for guidance.
Fetching is uncontentious, and I _think_ that fast-forwards are pretty
uncontentious as well.
so those people just need to use fetch instead of pull.
This seems fairly straightforward
fetch, get the data but don't integrate it
pull, get the data and ff along it if possible
pull with options, merge/rebase left/right based on options when ff is not
possible.
Pull was created with one workflow in mind, Changing it to require explcitly
specifying the option (in a config, with appropriate transition, handholding) is
not completly unreasonable, and given the confusion this causes, may be very
reasonable.
But saying that ff isn't always right, so make pull go away altogether (or
"don't change anything because there isn't 100% agreement on the result"
paralysis) doesn't seem right.
It's just when the merge-left/merge-right/rebase-left/rebase-right
decision kicks in that prescribing one git-pull behavior looks like a
recipe for trouble.
confusion at least. It's not fatal confusion, people have been using it for
years after all.
David Lang
(Apologies for not CCing all the folks who've participated in the
"Pull is
Evil" thread -- I couldn't find a good branch of that thread for this
message.)
OK, so maybe "git pull" is just Mostly Evil. People seem to have
found many
different ways to make it work for them.
But in reality "git pull" has become a chimera that confuses a large
number
of new users, and that experienced users either avoid entirely or
customize
to give them a convenient shorthand for working in their particular
environment. As a tool for new git users, it just doesn't seem to be
achieving its goals.
I think the git project as a whole would benefit if it started to
treat "git
pull" as an advanced command, in the sense that it needs to be
configured by
an experienced user in order to make it correctly follow a project's
workflow. Once it's configured properly, "git pull" is a powerful
tool that
gives users an easy way to do complex things. In that sense, it may
be
appropriate for a project to tailor "git pull" as it likes, then teach
its
own users to use the command.
However, when it comes to teaching people how to use git qua git, "git
pull"
should be the last thing they learn about, because it's only after you
understand various basic git concepts that you can configure "git
pull" to do
the right thing.
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't
been configured, and that the user should run "git help pull" for
guidance.
I tend to agree.
The hard part is making sure folk have enough prior learning to make a
choice that their will fit their real needs.
It'll take quite a bit of time, but I think that if we change our
attitude
towards "git pull" and take this unconfigured-by-default approach,
then in a
few years the entire git ecosystem will be in a better place.
M.
--
To that end, I suggest that pull's default behaviour should be to
do
*nothing*. It should just print out a message to the effect that
it
hasn't been configured, and that the user should run "git help
pull"
for guidance.
Fetching is uncontentious, and I _think_ that fast-forwards are
pretty
uncontentious as well.
While the fast forward is /pretty/ uncontentious, it still maybe
contentious for some.
So? No defaults can please absolutely everyone, the best anybody can
do
is try to please the majority of people, and merging fast-forwards
only
does that.
That assumes that doing something is better than doing nothing, which is
appropriate when the costs on either side are roughly similar. However
in this case, as we have essentially all agreed, there have been some
bad down sides. In that case a precautionary principle is more
appropriate where doing nothing (that is git pull does nothing until
user configured) is better.
While a shift to merging fast-forwards would reduce the cost difference,
they have to be matched against the potential user confusions when
comparing to all the old web miss-instructions, hence my shift away from
trying to best guess a default, rather than simply suggest it as a
suitable user choice.
From: Jonathan Nieder <hidden> Date: 2016-06-15 23:00:59
Hi,
Philip Oakley wrote:
That assumes that [git pull] doing something is better than doing nothing,
which is appropriate when the costs on either side are roughly
similar.
I think the conversation's going around in circles.
Potential next steps:
a. Documentation or test patch illustrating desired behavior
b. More traditional formal design doc explaining desired behavior and
the thinking behind it ("problem", "overview of solution",
"alternatives rejected", "complications", "example", "open
questions").
c. Implementation patch
d. Someone takes an existing patch and figures out the next step
toward getting it ready for application.
My preference is for (a), I guess.
The point being that something more concrete (code or a design doc)
makes it easier to avoid talking past each other. And having
something concrete to edit makes the stakes clearer so people can make
it incrementally better without being distracted by unimportant parts.
Thanks and hope that helps,
Jonathan
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:59
Philip Oakley wrote:
From: "Felipe Contreras" <redacted>
quoted
So? No defaults can please absolutely everyone, the best anybody can
do is try to please the majority of people, and merging
fast-forwards only does that.
That assumes that doing something is better than doing nothing,
When doing something is better for the vast majority of people, that's
what should be done by default, unless the results are catastrophic for
the minority.
Since doing something is not catastrophic to the minority, it follows
that the default should be to do something.
It's a simple as that.
--
Felipe Contreras
From: Philip Oakley <hidden> Date: 2016-06-15 23:00:59
From: "Felipe Contreras" <redacted>
Sent: Saturday, May 03, 2014 12:23 AM
Philip Oakley wrote:
quoted
From: "Felipe Contreras" <redacted>
quoted
So? No defaults can please absolutely everyone, the best anybody
can
do is try to please the majority of people, and merging
fast-forwards only does that.
That assumes that doing something is better than doing nothing,
When doing something is better for the vast majority of people, that's
what should be done by default, unless the results are catastrophic
for
the minority.
Since doing something is not catastrophic to the minority, it follows
that the default should be to do something.
That 'Since' and 'it follows' are where we have a diverging
understanding about the solution approach...
It's a simple as that.
... which makes it not quite as simple as that ;-) [evidence: the
ongoing dialog among all and sundry]
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:59
Philip Oakley wrote:
From: "Felipe Contreras" <redacted>
quoted
When doing something is better for the vast majority of people, that's
what should be done by default, unless the results are catastrophic
for
the minority.
Since doing something is not catastrophic to the minority, it follows
that the default should be to do something.
quoted
It's a simple as that.
... which makes it not quite as simple as that ;-) [evidence: the
ongoing dialog among all and sundry]
The dialog is not simple becuase it's not easy to make `git pull` do the
sensible thing. That doesn't mean `git pull` should do *nothing*, that
doesn't follow from the argument above.
--
Felipe Contreras
That assumes that [git pull] doing something is better than doing
nothing,
which is appropriate when the costs on either side are roughly
similar.
I think the conversation's going around in circles.
I agree it's going around, but it's a non-exact recurrence. Issues are
being surfaced.
Potential next steps:
a. Documentation or test patch illustrating desired behavior
b. More traditional formal design doc explaining desired behavior and
the thinking behind it ("problem", "overview of solution",
"alternatives rejected", "complications", "example", "open
questions").
c. Implementation patch
d. Someone takes an existing patch and figures out the next step
toward getting it ready for application.
My preference is for (a), I guess.
I disagree about the leap to the presentation & discussion of a
'solution' in these awkward scenarios (the old joke about "if I were you
I wouldn't start from here", when asking for directions tends to apply).
This is the same point made by Brooks in the 'Mythical Man Month'. A
leap to code is no guarantee of success.
The point being that something more concrete (code or a design doc)
makes it easier to avoid talking past each other. And having
something concrete to edit makes the stakes clearer so people can make
it incrementally better without being distracted by unimportant parts.
We've had Junio's training wheel, and now Filipe's n'th attempt at code
examples, so my bad code wouldn't help ;-). As a systems engineer I've
seen these confusions quite a few times in different guises.
I tend to fall back to P Checkland's "Systems Thinking, Systems
Practice" model of the various processes that have to go on [1] to
improve the situation (note he doesn't expect a solved solution in most
cases, just an improvement in the situation). At the moment most of the
discussion is in the "unstructured" parts of the processes. He also
identifies 6 elements 'CATWOE' [2] that need to be considered when
studying these problems.
Most of the discussion/arguments here are about the different
'Weltanshaung's" (world views) of the contributors.
In terms of the new user pull problem, what needs to be modeled is the
new user's and their weltanshaung, not how we ('experienced' users?)
might 'solve' the problem.
The pull problem is, I believe part of the bigger problem of the
mind-set shift required for the transition to a DVCS for most new users.
Git has grown organically, so still has some soft (unclear) edges, which
probably needs more than just a transition plan for Filipe's pull
changes, and its choice of the final default (or lack of).
For example, if users aren't understanding the differences between
remote branches, remote tracking branches, and branches, which is part
of the pull problem; have we made it easy for them to understand? [They
already have to comprehend the 'staging' concept, so are already
cognitively fully loaded].
For the branch type example, some cleaner naming may help, such as:
'remote branch', 'Tracking branch', and '(local) branch', which excludes
the noiseword 'remote' from 'Tracking branches' (my deliberate 'T'
emphasis). Though that does still leave the confusion between remote
servers and remote repos, where the latter may actually be local, and if
a file path, be the local '.' repo itself!
Thanks and hope that helps,
Sorry if this went off at a tangent, but I believe it's important to get
to the bottom of the new user problems, which are deeper than just a few
command defaults.
From: Marc Branchaud <hidden> Date: 2016-06-15 23:01:05
After poking this hornet's nest I pretty much have stood back and not
participated in the ensuing discussions. But having unleashed the hornets I
feel I should at least say something, if only to assure people that I'm not
ignoring their plight.
There have been various proposals to modify git-pull's defaults, and/or
extend it with new configuration settings, and/or add a new command. As I
don't use "git pull" I feel I'm not in any position to comment about the
particulars of these proposals.
However I remain skeptical that these proposals, in any form, will really be
all that helpful to new users. That's because in order to know whether or
not "git pull" (or "git update") does what the user wants, the user has to
understand the intricacies of both their own workflow and how git can work
within that workflow. By the time a user gains that understanding, she is no
longer a new user.
Still, I do think the pull command is useful. In particular I think that a
project can benefit greatly by tailoring pull's behaviour to match its
workflow, and that a project's participants can be told how to configure git
so that pull works properly for that project. Maybe even such configuration
-- a "workflow blueprint" if you will -- can be tracked inside the project
itself, so that a fresh project clone can automatically have "git pull"
properly configured. To me this seems like a fabulous feature for git.
But for now I go back to what I said before: Give "git pull" enough knobs to
let people tailor it to their individual projects' needs. But also disable
"git pull" by default, because nobody should run it until they've considered
how they want it to work.
M.