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:
How to make pull requests *without* a github account? (2012-03-09)
Why Linus Thorvalds doesn't do github pull requests. (2012-05-11)
The git request-pull command.
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
orgit commit
andgit 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 🙂