This is an old version of this page. You can view the most recent version or browse the history.

This page will be moved to a proper place later. It is written here to simplify the authoring / review process.

Using merge requests

Submitting a merge request

Commit in a branch and submit merge request to merge this branch in master.

Breifly describe the reasons for these changes in the merge request description. No need to repeat the individual commit messages.

Reviewing a merge request

Make sure the merge requests contains test. If this is a new feature, a test must exercice this new feature. If this is a bug fix, then a test to reproduce the fixed bug is usually required.

Make sure the merge request comply with:

Naming conventions http://www.erp5.org/GuidelinesForNamingConvention
If this is ERP5 modules / business templates http://www.osoe-project.org/bt5-Module.Creation.Guidelines
Other guidelines http://www.erp5.org/Guidelines

Make sure the merge request does not contain performance crimes .

Accepting / rejecting a merge request

( when to use apply patches / merge as topic ? )

Tips

Using interdiff

After updating patches following up reviewers suggestion, the review process can be simplified if submiter produces an interdiff to show clearly what is different with the new version of the patches.

There is interdiff command to create diff between 2 patches:

http://linux.die.net/man/1/interdiff
(package patchutils usually)

we can use it in combination with git:

$ git diff origin/master...t   >1      # diff for first patch version (NOTE 3 dots)
$ git diff origin/master...t2  >2      # diff for second patch version
$ interdiff 1 2

Now this can be simplified to

$ interdiff <(git diff origin/master...t) <(git diff origin/master...t2)

In case you have the changes on your own single branch and update that branch on server via git push it can be

$ interdiff <(git diff origin/master...camata/branchname@{1}) <(git diff origin/master...camata/branchname)

Note @{1} here - it means how that branch was 1 change before. (You can read more about it in git-reflog documentation https://git-scm.com/docs/git-reflog)

Generally speaking using plaing git diff t t2 is not correct, because base revision for those two patchsets can be different (origin/master could be not the same for t2, compared when t was created) and the diff will include what has been changed in origin/master@{1}..origin/master - not your changes.

But in case base commit is the same, plain git diff t t2 or git diff camata/branchname@{1}..camata/branchname works ok.

Home