[cfe-dev] [llvm-dev] [lldb-dev] [GitHub] RFC: Enforcing no merge commit policy

[Kim Gräsman via cfe-dev]

On Sat, Mar 23, 2019 at 2:10 AM Mehdi AMINI via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
> On Fri, Mar 22, 2019 at 3:40 PM Joerg Sonnenberger via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>
>> On Fri, Mar 22, 2019 at 04:39:26PM +0000, David Greene via llvm-dev wrote:
>> > One consequence of this is that release branches can be more easily
>> > validated.  In a world with merge commits, many projects make fixes on
>> > the release branch *first*, then merge the release branch to master,
>> > ensuring that fixes in the current release make it into the next release
>> > (when that is branched off master in the future).
>>
>> This always felt strongly like a design deficit of git and not a feature
>> that should be advertised. That is, lack of proper cherry-picking meta
>> data is the main bug and the back-way model of committing to the oldest
>> release branch first is the consequence.
>
> I'm not sure I understand? In a model where you would commit to trunk and cherry-pick to
> a release branch, and never commit directly to the release branch (which looks like what
> LLVM is doing), what is the issue with the lack of cherry-picking metadata?

The cherry-picked commit will get a new SHA, so the same patch will
exist multiple times with different SHAs through the commit graph.

That (unless I'm missing something) makes it impossible to do `git
branch --contains=<bugfix-sha>`, which can be really handy to check
which releases contain a commit of interest.

- Kim