Re: [RFC PATCH] push: start warning upcoming default change for push.default

Dmitry Potapov [off-list ref] writes:

On Wed, Mar 14, 2012 at 6:47 PM, Matthieu Moy
[off-list ref] wrote:

quoted

Dmitry Potapov [off-list ref] writes:

quoted

Not of course. I said above non-fast forward push should not be used by
beginners.

Do you mean "beginners should not force non-fast forward push", or
"beginners should not use flow where push may be denied because of
non-fast forward"?

Of course, the former. I have never said that the centralized workflow
should never been used. I have only said that it is not scalable and
lead to problems in larger projects.

Then I don't follow you. The starting point of the discussion was my
rule of thumb about push/pull:

| There's a rule of thumb which works very well for beginners: when "git
| push" tells you to pull before, then pull before. This rule of thumb
| works, but only provided "push" and "pull" are symmetrical.

I can rephrase the end as "... provided 'push' pushes to the same branch
'pull' pulls from" (i.e. provided push.default=upstream).

Can you explain what you disagree with here? Or do you actually agree
with it?

Then, I showed the message of "git push" in the non-fast forward case,
which suggests that the user should pull, and you said:

| I agree that the current diagnostic is not suitable for beginners.

Again, what do you mean? What diagnosis would you suggest, if not
pulling?

quoted

either shared for one user and multiple machines, or shared
between developers?

I am not sure that I understood this part.

I mean that a repository can be shared because multiple developers have
acces to it, or because the same developer has several clones.

quoted

If you mean that shared repositories are too complex for beginners, my
experience is exactly the opposite.

It is not too complex but it is wrong for any more or less serious
project.

I never argued against distributed development. I'm saying that
centralized development also makes sense, especially with beginners.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/