On Fri, Dec 11, 2020 at 5:22 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > > The discussion about making fast-forward-only pulls the default is > > stuck on mud, and there's no agreement about what we should even > > be warning our users about. > > The above perception of yours is mostly due to misunderstanding, I > would have to say. We are in agreement on what we should be warning > about at least, assuming that you are expressing what you want > clearly in the latest round of responses and I understood them > correctly [*1*]. I'm not trying to be difficult here, but at every round where you have stated what it is that I want, it's not actually what I want, and the last round is no exception, in my option. Let's assume that I'm not explaining clearly what I want. In the last round you said you wanted an error, not a warning. That's not what I want; I'm proposing a warning. But that's not what I was referring to here. > I do not know if others on the list agree, though. This is what I was referring to. Initially there seemed to be some interest, and suddenly that interest disappeared. > I do agree that there is no agreement on the behaviour in the > endgame. See? I disagree. I think the endgame is clear. How we get there is where there's no agreement. > In principle, I am in favor of disabling the more > dangerous half of the "git pull" command for those who haven't > configured anything. But I can understand those who do not want > that behaviour, as the fallout would be quite big. And who is that? Did anyone in the list express that they did not want that behavior? > > Even my straightforward patches about improving documentation, and > > the consistency of the UI with --merge and other obvious fixes > > lost traction. > > It may be obvious to you, but may not be to others on the list who > spoke in the thread and who didn't speak but read the discussion. > > I did see potential goodness in the documentation update and that > was why I offered polishment on top of your patches in a v3 round, > but seeing the suggestions dismissed without convincing arguments > before v4 was sent out would have discouraged even the most patient > reviewers among us. If you meant by "lost traction" the lack of > comments on v4, that was my reason for not commenting. I did not dismiss your suggestions, I replied to your suggestions [1]. You did not reply back. Moreover, in patch 2 I saw you had some confusion [2], in which you said you didn't see any value in updating the message without changing the condition that triggers, to which I replied [3]: "Maybe it will be clearer when I send all the patches." That's why I sent v4; not because I thought the review of v3 was done, but because we were stuck not seeing the evolution of the warning. In v4 I went through every step of the evolution [4], and I went back to what I said in v3: At this point we can update the warning to mention that we are inside a non-fast-forward case. But it's not necessary. So I did not dismiss the suggestion, I replied to it, and put a pin on it. You can certainly bring the same suggestion in v4, but I seem to have convinced Elijah Newren that "fast-forward" can be used as an adverb perfectly well, and it in fact is, in many places in the documentation both internal, and external. > In any case, these three patches in this round looked quite sensible > to me, except for the tests in 3/3, and minor details of 2/3, both > of which I gave a more detailed review and suggestion. Great. That should improve the situation of most users. And also has the added benefit that it's 3 less patches I have to carry around on every round. Cheers. [1] https://lore.kernel.org/git/CAMP44s1ZDXzGfEqpTeiG=aGAYK40ebnBLQKAbA7KGtcePGARfw@xxxxxxxxxxxxxx/ [2] https://lore.kernel.org/git/xmqq4kkx9vzx.fsf@xxxxxxxxxxxxxxxxxxxxxx/ [3] https://lore.kernel.org/git/CAMP44s1aYqzCVvELH8zULaTkOdgLSSAQ0LE8WfgQKLPfU2MHfg@xxxxxxxxxxxxxx/ [4] https://lore.kernel.org/git/CAMP44s2hUCd9qc83LReGyjy8N+u++eK6VjwGhDhrX0f0SbKmig@xxxxxxxxxxxxxx -- Felipe Contreras
