All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git <git@vger.kernel.org>, "Elijah Newren" <newren@gmail.com>,
	"Jeff King" <peff@peff.net>, "Vít Ondruch" <vondruch@redhat.com>
Subject: Re: [PATCH v5 0/3] pull: stop warning on every pull
Date: Fri, 11 Dec 2020 07:28:24 -0600	[thread overview]
Message-ID: <CAMP44s0uyxs4p+HJ5ZDrrKJs9wQW4tSCZzPonpvP=FcTGCcxSA@mail.gmail.com> (raw)
In-Reply-To: <xmqqo8j0io39.fsf@gitster.c.googlers.com>

On Fri, Dec 11, 2020 at 5:22 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> 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@mail.gmail.com/
[2] https://lore.kernel.org/git/xmqq4kkx9vzx.fsf@gitster.c.googlers.com/
[3] https://lore.kernel.org/git/CAMP44s1aYqzCVvELH8zULaTkOdgLSSAQ0LE8WfgQKLPfU2MHfg@mail.gmail.com/
[4] https://lore.kernel.org/git/CAMP44s2hUCd9qc83LReGyjy8N+u++eK6VjwGhDhrX0f0SbKmig@mail.gmail.com

-- 
Felipe Contreras

  reply	other threads:[~2020-12-11 13:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 10:05 [PATCH v5 0/3] pull: stop warning on every pull Felipe Contreras
2020-12-10 10:05 ` [PATCH v5 1/3] pull: refactor fast-forward check Felipe Contreras
2020-12-11  6:54   ` Junio C Hamano
2020-12-12 15:18     ` Felipe Contreras
2020-12-10 10:05 ` [PATCH v5 2/3] pull: move default warning Felipe Contreras
2020-12-11  6:54   ` Junio C Hamano
2020-12-11  7:55     ` Felipe Contreras
2020-12-12  0:00       ` Junio C Hamano
2020-12-12  1:05         ` Felipe Contreras
2020-12-13 20:58           ` Junio C Hamano
2020-12-14 11:02             ` Felipe Contreras
2020-12-12 16:42       ` Felipe Contreras
2020-12-10 10:05 ` [PATCH v5 3/3] pull: display default warning only when non-ff Felipe Contreras
2020-12-11  7:16   ` Junio C Hamano
2020-12-11 12:48     ` Felipe Contreras
2020-12-11 23:56       ` Junio C Hamano
2020-12-12  1:01         ` Felipe Contreras
2020-12-12  2:11         ` Junio C Hamano
2020-12-12 16:01           ` Felipe Contreras
2020-12-14 21:04             ` Junio C Hamano
2020-12-14 21:40               ` Felipe Contreras
2020-12-11  7:17 ` [PATCH v5 0/3] pull: stop warning on every pull Junio C Hamano
2020-12-11 13:28   ` Felipe Contreras [this message]
2020-12-12  2:50     ` Junio C Hamano
2020-12-12 16:36       ` Felipe Contreras
2020-12-14  0:57         ` Felipe Contreras
2020-12-12 16:52 Felipe Contreras
2020-12-12 16:56 ` Felipe Contreras

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='CAMP44s0uyxs4p+HJ5ZDrrKJs9wQW4tSCZzPonpvP=FcTGCcxSA@mail.gmail.com' \
    --to=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=vondruch@redhat.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.