Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 16, 2016, 17:47 UTC
Message-ID: <xmqq1t1oehbz.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kby02NuRvQkcuTNjxxc4oDvjAH4wE=3dCXmqyRRrCU0tQ@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 14 quoted lines

> In your work flow, how do you respect the cover letter?
> e.g. in 3787e3c16ced:
>
>     Merge branch 'ew/http-backend-batch-headers'
>
>     The http-backend (the server-side component of smart-http
>     transport) used to trickle the HTTP header one at a time.  Now
>     these write(2)s are batched.
>
>     * ew/http-backend-batch-headers:
>       http-backend: buffer headers before sending
>
> Is the text from the original author (and if so from which version
> of the cover letter) or is it your work?

The source of truth in the merge log message is the "What's cooking" report. I really prefer to write these in my own words, as that is a good yardstick to measure how much/little I understand the topic. If I cannot describe it concisely, in a way suitable as an entry in the release notes, that means I am merging a topic I do not have a good idea about, which is quite irresponsive. Forcing me to write these myself keeps me honest.

Of course, if a cover letter describes the topic well, it would help me write the entry in the "What's cooking" report.

It is a bit tricky to aim for the automation, though. The cover is an overview of the proposed log messages and typically tells a story "I do this, and then this, and finally that", plus a reroll-specific commentary like "what changed since the last round". On the other hand, the entries in the release notes gives a description of what happened from a third-party's point of view. They are told in different voice for different target audience.