Welcome | Get started | Dive into Lino | Contribute | Reference

How to submit a pull request

Send a patch

The easiest and most basic way of contributing a code change is to send a patch. Here is how to do that.

  • Go to the project root directory and type:

    $ git diff > mypatch.txt

  • Send the file mypatch.txt or its content via e-mail to lino-developers@lino-framework.org or directly to a committer (somebody who has write permission to the public code repositories).

One disadvantage of this method is that your contribution is not visible in the history of the repository.

Using GitHub

You use the GitHub web interface as explained in Creating a pull request. We accept this way of communication.

Using git request-pull

The problem with using GitHub pull requests is that this approach partly relies on proprietary software. Some more thoughts about this:

So the following would be our recommended way of making pull requests.

Preparation:

  • Make sure that you have no local changes in your project repositories.

  • Create a fork (on GitHub or somewhere else) of the repositories you are going to work on.

  • Change the remote of your local copy so that it points to your fork. Add an upstram remote. Setup your git credentials. (TODO: explain more details)

For each request:

  • Work in your local clone of that repository.

  • Publish the changes in your working copy to your public repository using inv ci or git commit and git push.

  • run git request-pull

Pushing directly to master branch?

Hell is when people push directly to master branch. That's at least what this thread on Reddit suggests. The resulting discussion is interesting. Obviously there are different religious schools about the topic. Well-educated project managers seem to be horrified and ask "Who lets people push to master without a pull request and code review?", but others have obviously been in that "hell", and they report quite positive things about it:

  • It depends on what the workflow for git is. If you CI/CD deploys to production on a push to master, well you shouldn't push to master obviously. If "master" is the bleeding edge branch that may be broken from time to time, then it's not that big of a big deal. For example, Google does it that way in Flutter. Master is only "Usually functional, though sometimes we accidentally break things.". After testing, master gets merged into "dev", then "beta", then "stable".

  • We push to master in my current role and I have in all my jobs for the last 10+ years. We do ci/cd, feature toggles and automated testing. Pairing is how we do code reviews. Honestly nothing wrong with it 🙂