Re: [PATCH v2 0/1] scalar: move to the top-level, test, CI and "install" support

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Especially as I'm not insisting that I be the one to drive anything
> forward on the scalar topic, I think it makes much more sense that it's
> Victoria.
>
> This patch is just offered as a way to help that effort along. Perhaps
> she'd ack it as-is, find it useful as it reveals some edge cases she
> didn't know about, or drop it and go for some other approach. Whatever
> gets us to the end-goal sooner than later is fine by me.

Careful ...

> Once you "git rm" the scalar Makefile there's not really a lot of ways
> you can go other than something approximating the upthread patch. Given
> that some of the edge cases are tricky I deemed it worthwhile to share
> it.
> ...
> I'm not saying that, but "you seem to be trying to do X, and may or may
> not be aware of a past patch that does X, here is is in case it help!.
> ...
> Some of the edge cases in the Makefile integration are subtle. I trust
> that someone looking at it would probably discover those eventually.

... Even though you ask to assume good intent, an attitude shown by
repeated "I've done that, I already know *the* solution to the
problem you are trying to solve, and you can learn from what I did"
gives recipients quite an impression different from what you intend
to give.

> But if I'd have gotten a patch from my future self with all the learned
> edge cases beforehand I'd have appreciated, so I figured I'd send it in.

In any case, if you stop sending *replacement* patches in response
to others' work, that alone will reduce the friction people around
you are feeling quite a lot.  A replacement patch is a horrible and
inefficient way to comment on others' work, if your goal is to be
understood.  The recipient would be forced to read and think like
you did, making comparison between the two approaches themselves if
they want to see if it is worth to use the replacement.

Making comparison between approaches, arguing for the alternative
approach to be better, and proposing the alternative to be taken, is
the responsibility of the party who is suggesting alternative
approaches, not that of the recipient.

For that reason, if you want to say something to other people's
work, you are better off doing that either by commenting in-line
(i.e. annotating their code you want to comment on), or if you
absolutely need to talk in code, or by giving an incremental update
once their work solidifies (i.e. pointing out a specific issue in
the existing code, explaining why it is a problem worth addressing,
and offering an update---just like when you are fixing a bug).

Thanks.