Re: Handling pullups

[Greg Troxel <gdt%lexort.com@localhost>]

coypu%sdf.org@localhost writes:

> One of the suggestions was pullups might be best handled by
> creating a one-off branch for the pullups, where commits are
> grafted and merges are resolved, putting the vast majority of
> must-be-manual burden on just the submitter (as opposed to "both the
> submitter and releng")
>
> I really like this idea, but wondered: how should we handle the
> naming of branches? if we use branches that are later removed, then we
> can freestyle.
> Otherwise, we'll probably want some consistent naming policy like
> pullup_pkgsrc_firefox_65_0_1.

In a large project where I set the git usage rules, we were very
protective of master as the place of current development, with review
and approval before merge.  (That's different from NetBSD and I'm not
trying to change that.)

People would create a branch "feature.NNN.short-description" with their
changes (NNN being ticket number).  They would then need to have it
reviewed by someone, and pass tests.  Then a merge approver could verify
review/test and give approval.  For a branch to be mergeable it had to
be rebased so that the ancestor of the first commit on the branch is the
tip of master.

We then merged with "--no-ff", so there was an explicit merge commit
with the "Fixes: NNN" for trac and with the approver's name.  More
importantly, it meant that the first-parent ancestry of master pointed
to the previous tip of master, and the new branch was the second-parent.
Thus "git log" on master showed almost entirely merge commits.

The branch name was then deleted after merge (but the name lived on in
the merge comment).

Overall this worked extremely well.  It's surely too much for master
given our culture, but seems like a reasonable model for pullups.
Probably relaxed to "ancestor is recent on the stable branch, and no
file is modified on both unmerged stable branch commits an branch
commits" or "obviously automatic merge is 100% correct textually and
semantically".