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

Start by forking the repository, commit in a branch in your personal repository 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

Checking out merge requests locally

git config --add remote.origin.fetch '+refs/merge-requests/*/head:refs/remotes/origin/mr/*'

Then you can

git checkout mr/123

Producing 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, source here)

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.

Home