You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rafael Weingärtner <ra...@gmail.com> on 2018/03/22 10:27:10 UTC

Re: [DISCUSS] new way of github working

These last two months I have experimented working with both ways
(maintaining the merge commit and squashing and merging). When I
experimented using “squash+merge”, the only time I was maintaining the
merge commit is during merge-forwards.

I liked working with “squash+merge” approach. This allowed me to split my
PRs into multiple commits, which facilitates for reviewers. For instance,
it is interesting to split code changes and formatting ones. Moreover,
during the review of the PR, we can create a history of changes that were
created because of reviews. Then, when everything is ready to be merged, we
can squash everything (using Github UI), and merge the PR as a single
commit. Of course, to adopt this method we need to present single changes
per PR. Meaning, a PR should not address multiple issues at the same time.

One thing we need to change though. When merging forward we must customize
the “forward merge” message. Otherwise, we end up with a bunch of commits
that have the same commit title (e.g. “merge 4.11”). We can use messages
such as “Froward merge #<prNumber> from <branch>”, and then add in the body
of the commit the title of the commit that was used to merge the
#<prNumber>.

What do you guys think? Let’s finalize this discussion and define a
standard to adopt. Then, I can change the merging tools (are people using
them after we moved to Github?) accordingly (if needed). I can also update
the merge document that is on our wiki page.

On Mon, Jan 15, 2018 at 6:47 PM, Rene Moser <ma...@renemoser.net> wrote:

>
>
> On 01/15/2018 09:06 PM, Rafael Weingärtner wrote:
> > Daan,
> >
> > Now that master is open for merges again, can we get a feedback here? It
> > might be interesting to find a consensus and a standardize way of working
> > for everybody before we start merging things in master again …
>
> +1 to allow merge commits on master branch to keep history of a series
> of patches when they help to understand the change.
>
> René
>
>
>


-- 
Rafael Weingärtner