[Pulp-dev] Merging forward commits

[Alan Conway]

On Thu, 2017-02-02 at 16:46 +0100, Michael Hrivnak wrote:
> This comes up periodically, and we've had split opinions for a long
> time. I've been in the camp that likes merging, and finds it
> intuitive. But I'm open to trying cherry-picking since there is a lot
> of interest.
> 
> I must admit, I am always surprised when people describe merging
> forward as complicated. For me, it boils down to this:
> 
> - Features happen on master. No merging or cherry-picking required.
> - Bug fixes happen on the last release branch. Merge your bugfix
> branch to master and the release branch. Simple.
> - Hotfixes are a rare exception that require slightly more thought,
> but are still easy to reason about. If in doubt, "git merge-base
> [list all the places you want to merge your fix]" tells you where to
> branch from.
> 
> That's the extent of my thought process when merging forward. I am
> generally interested to know more about how this process causes
> friction.

Can't speak for the pulp upstream but the qpid community also prefers
to keep the commit history linear as far as possible. Partly that's
because they come from using SVN, which made branching nightmarishly
hard to follow. ("SVN, it sucks slightly less than CVS!")

The advantage of cherry-picking and/or rebasing is that it keeps the
master branch in one straight line, which many find easier to read. The
disadvantage is you don't take advantage the full power of git to track
where the commits came from.

In an ideal world I'd merge anytime the branches involved are already
public. However in the communities I'm in, rebase/cherry-pick is
preferred and it works fine in practice. 

> 
> But all of that said, I'm very happy to give cherry-picking a try. As
> Brian said, my main concern would just be tracking where a change has
> been applied. This is something I value a lot in the merge model.
> 
> If we do switch, I think we should first write down specifically what
> benefits we expect to get. That would help in two ways: 1) Make sure
> everyone is on the same page about what we expect to gain. I suspect
> there are differing assumptions across the group. 2) Enable us to
> evaluate afterward to what extent the change was successful.
> 
> Lastly, our current branching model was inspired by this classic
> approach:
> 
> http://nvie.com/posts/a-successful-git-branching-model/
> 
> If you're not familiar, it's worth a read for perspective. Their
> "develop" branch is our "master". And obviously we don't do things in
> quite the same way, but the general principles are the same. 
> 
> Michael
> 
> On Thu, Feb 2, 2017 at 3:34 PM, Brian Bouterse <bbouters at redhat.com>
> wrote:
> > The main concern for me is how to track the cherry picks in
> > Redmine. Using the rebase and merge approach, or if Github had a
> > dedicate cherry pick feature, we still need a way in Redmine to
> > know if any given bugfix has been applied to older release streams,
> > i.e. the current bugfix release stream.
> > 
> > On Wed, Feb 1, 2017 at 12:18 PM, Jeremy Audet <jaudet at redhat.com>
> > wrote:
> > > > Thinking out loud, it would be nice if github would support a
> > > "cherry pick" PR
> > > 
> > > I think you can. The submitter just needs to open a PR against
> > > some branch other than master, and the merger needs to select the
> > > rebase and merge GUI option.
> > > 
> > 
> > 
> > _______________________________________________
> > Pulp-dev mailing list
> > Pulp-dev at redhat.com
> > https://www.redhat.com/mailman/listinfo/pulp-dev
> > 
> 
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev