[Pulp-dev] Merging forward commits

[David Davis]

I was wondering if it might be worth considering cherrypicking commits to
release branches instead of merging them forward from release branches. I
might be a bit biased coming from Katello where we have done this for a
while. For one thing I noticed that the git history in Pulp is very
convoluted because of all the merge commits. Here is the git history of
master in katello (bottom) compared to the git history of master in pulp
(top):

https://i.imgur.com/PR5vNBZ.png

I think cherrypicking commits from master to release branches could also
simplify our workflow a bit. Right now you have to identify what branch
needs a hotfix before you open the PR and then you also have to update the
appropriate branch(es) after merging. I think this presents a barrier to
entry for community contributors by asking them to open a PR against a
specific branch if they want to fix a bug instead of just master (which is
the common paradigm in open source). Instead, with cherrypicking hotfixes,
we’d only have to worry about updating branches as part of merging—which we
have to do anyway as part of merging forward commits.

There might instances where this workflow doesn’t work as well as merging
forward commits—namely when there are conflicts on a rebase branch or we
need to test something specifically against a release—but I think we could
just handle those one-off cases as they arise.

Thoughts?

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170130/0105ca37/attachment.htm>