Thread (5 messages) flat view 5 messages, 4 authors, 2016-06-15

Re: Pull is Evil

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:00:57

Marc Branchaud [off-list ref] writes:
On 14-04-30 10:55 AM, Junio C Hamano wrote:
quoted
Marc Branchaud [off-list ref] writes:
...
quoted
quoted
Anyway, rather than ranting on I'll just suggest that there's not enough
commonality between the ways people use git to make it worthwhile trying to
teach pull how to deal with a significant number of them.  I think the pull
command should be deprecated and quietly retired as a failed experiment.
I almost agree with the first sentence in the last paragraph, and
your bulletted list above supports it.

I am not sure how the second sentence can follow as its consequence.

If the conclusion were "maybe adding a 'git update' to match the
expectation of those who build on top of the work of others (aka
CVS/SVN style) more  closely and teaching new users to use that
instead of 'git pull' may be a good way forward", I can sort of
understand (if I may not be able to immediately agree with, until I
can regurgitate the ramifications of such a change) it.
I think we would run into much the same problem with "git update" as we do
with "git pull"....
Maybe I was unclear.

I didn't mean "replace 'pull' with 'update' everywhere".  I meant
"Introduce 'update' that lets integrate your history into that from
the remote, which is to integrate in a direction opposite from how
'pull' does".  

Then the downstream people (i.e. by definition, most of us) would
use "git update" while integrators would use "git pull".  There is
no workflow assumption if we do so.
I don't think we'll ever be able to create a One "Git Pull" To Rule Them All.
Yes, that is exactly why I mentioned "git update".

Another way not to make any workflow assumption is to ask the user
to tell us.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help