Drop last MakeMaker reference

[dscho]

Back when we stopped using MakeMaker, we forgot one reference...

[dscho]

/submit

[gitgitgadget]

Submitted as pull.146.git.gitgitgadget@gmail.com

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> Back when we stopped using MakeMaker, we forgot one reference...
>
> Johannes Schindelin (1):
>   mingw: drop MakeMaker reference
>
>  config.mak.uname | 1 -
>  1 file changed, 1 deletion(-)
>
>
> base-commit: 8104ec994ea3849a968b4667d072fedd1e688642
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-146%2Fdscho%2Fno-perl-makemaker-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-146/dscho/no-perl-makemaker-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/146

Good ;-)
Thanks.

[gitgitgadget]

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio,

On Sun, 3 Mar 2019, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > Back when we stopped using MakeMaker, we forgot one reference...
> >
> > Johannes Schindelin (1):
> >   mingw: drop MakeMaker reference
> >
> >  config.mak.uname | 1 -
> >  1 file changed, 1 deletion(-)
> >
> >
> > base-commit: 8104ec994ea3849a968b4667d072fedd1e688642
> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-146%2Fdscho%2Fno-perl-makemaker-v1
> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-146/dscho/no-perl-makemaker-v1
> > Pull-Request: https://github.com/gitgitgadget/git/pull/146
> 
> Good ;-)
> Thanks.

Gentle reminder that this has not made it into `pu` yet...

Thanks,
Dscho

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi Junio,
>
> On Sun, 3 Mar 2019, Junio C Hamano wrote:
>
>> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
>> writes:
>> 
>> > Back when we stopped using MakeMaker, we forgot one reference...
>> >
>> > Johannes Schindelin (1):
>> >   mingw: drop MakeMaker reference
>> >
>> >  config.mak.uname | 1 -
>> >  1 file changed, 1 deletion(-)
>> >
>> >
>> > base-commit: 8104ec994ea3849a968b4667d072fedd1e688642
>> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-146%2Fdscho%2Fno-perl-makemaker-v1
>> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-146/dscho/no-perl-makemaker-v1
>> > Pull-Request: https://github.com/gitgitgadget/git/pull/146
>> 
>> Good ;-)
>> Thanks.
>
> Gentle reminder that this has not made it into `pu` yet...

Thanks.

I'll try to make it a habit not to respond to 0/1 (but instead to
1/1) as it is quite inefficient to get to 1/1 from 0/1 at least for
me X-<.

Or perhaps GGG can learn to avoid 0/1 for a single-patch topic ;-)

Thanks anyway.  Will try to apply directly on top of master.

[gitgitgadget]

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio,

On Fri, 8 Mar 2019, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Sun, 3 Mar 2019, Junio C Hamano wrote:
> >
> >> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> >> writes:
> >> 
> >> > Back when we stopped using MakeMaker, we forgot one reference...
> >> >
> >> > Johannes Schindelin (1):
> >> >   mingw: drop MakeMaker reference
> >> >
> >> >  config.mak.uname | 1 -
> >> >  1 file changed, 1 deletion(-)
> >> >
> >> >
> >> > base-commit: 8104ec994ea3849a968b4667d072fedd1e688642
> >> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-146%2Fdscho%2Fno-perl-makemaker-v1
> >> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-146/dscho/no-perl-makemaker-v1
> >> > Pull-Request: https://github.com/gitgitgadget/git/pull/146
> >> 
> >> Good ;-)
> >> Thanks.
> >
> > Gentle reminder that this has not made it into `pu` yet...
> 
> Thanks.
> 
> I'll try to make it a habit not to respond to 0/1 (but instead to
> 1/1) as it is quite inefficient to get to 1/1 from 0/1 at least for
> me X-<.

Hehe. I do have something for you there:

https://github.com/git-for-windows/build-extra/blob/master/apply-from-public-inbox.sh

-- snip --

> Or perhaps GGG can learn to avoid 0/1 for a single-patch topic ;-)

It is easier, and more consistent, to have a cover letter even then, for
things like the broader explanation of the context, the changes since the
previous iteration, and the range-diff (which would make v2, v3, v4, etc
utterly unreadable from my point of view if they were integrated into the
single patches, as I used to do with interdiffs).

> Thanks anyway.  Will try to apply directly on top of master.

Thank you!

While we're talking about "directly on top of master"... *after* it got
some review, I would love to ask for the same favor for
https://public-inbox.org/git/pull.160.git.gitgitgadget@gmail.com

On the other hand, it is an old bug, I know, and it will break all CI
builds for branches that are based off of older commits, anyway. I guess
we'll need some sort of horrible hack in the git-sdk-64-minimal thing, to
allow for patching this on the CI side, without adding commits to all of
those branches. :-(

So: I made up my mind, and that MSYS2 runtime v3.x patch does not need to
be fast-tracked; it would not fix all the CI builds...

Ciao,
Dscho

[dscho]

Applied directly to git.git's master as 6053c04

[gitgitgadget]

On the Git mailing list, Jeff King wrote (reply to this):

On Fri, Mar 08, 2019 at 05:27:36PM +0100, Johannes Schindelin wrote:

> > Or perhaps GGG can learn to avoid 0/1 for a single-patch topic ;-)
> 
> It is easier, and more consistent, to have a cover letter even then, for
> things like the broader explanation of the context, the changes since the
> previous iteration, and the range-diff (which would make v2, v3, v4, etc
> utterly unreadable from my point of view if they were integrated into the
> single patches, as I used to do with interdiffs).

Just my two cents:

As a reviewer, I generally prefer not to see a separate cover letter for
a single patch. At least for the first version (I agree it gets unwieldy
showing a range-diff after the "---" for subsequent versions, unless it
happens to be pretty short).

My reasoning is that I've noticed that many of the GGG-sent patches
often end up duplicating quite a bit of content between the cover letter
and the commit message of the patch (or worse, putting things only in
the cover letter that really could go into the commit message). That
doubles the time I spend reading and understanding the patch's rationale
(and I'm speaking subjectively here, of course; I didn't measure it).

I don't think it's an _inherent_ problem with a separate cover letter.
But something about the workflow causes people to write up over-long
cover letters. Which presumably is the fact that they're presented with
a PR textbox to write the rationale separately from when they wrote the
commit message. So they err on the side of repeating themselves, and
never see the two pieces "together" (like the reader will), which makes
the redundancy more obvious.

I'd say 99% of the time a single-patch doesn't need any cover letter
material at all. And even a multi-patch series really just needs a tl;dr
of the problem and a sketch of the solution. In both cases, the commit
messages should carry the meat.

(That's all specific to our project, of course; I know many projects
don't care about commit messages at all and expect PR descriptions to be
the first-class explanations).

-Peff