How to contribute to this website (and send your final report)
All it takes is a terminal in which you can run git on the command line. And a mail client.
Warning: git should be used from the command line (to force you to learn). Use of VSCode is banned as it could break filenames and folder structure.
Cloning the project
You should maintain a local copy of the repository of the course. The course is hosted on Sourcehut (not Github. Git is not Github and you will be asked about it at the exam). You should NOT create any sourcehut account (it is not required).
git clone https://git.sr.ht/~lioploum/linfo2401/
Now that you have a local version (in the "linfo2401" folder), you should update it periodically.
cd linfo2401 git pull
You can explore the course project.
Commiting your changes locally
Let’s say that you have fixed a typo. Or you have added your report to the repository.
First thing is to commit your change locally. Don’t forget to give a good description to your commit when asked.
git add PATH_TO_MODIFIED_FILE git commit
You can also include the change directly with
git commit -m "Adding report by Lionel Dricot"
Try to keep your modifications in one meaningful commit. If you change something after the commit, simply amend it. This will add the new modifications to the previous commit and will ask if you want to modify the description.
git commit -a --amend
WARNING: amending a commit can only be done with local commits. If you amend a commit that was already pushed, your repository will diverge from upstream. Not something you want before becoming more familiar with git.
Preparing your repository to send commits
Unlike Github or Gitlab, there’s no Pull Requests and web interface. Instead, your commit will be sent as a patch by email. Don’t worry, it is easier than it looks.
If it’s the first time you send a git patch by email, your computer may requires some configuration. Follow the git-send-email tutorial.
If it is not sufficient, some information could be found on the Linux kernel development documentation. In most cases, this is not needed.
Now, in your local linfo2401 folder, we will set the mailing-list as the default destination for patches. This should only be done once.
git config sendemail.to "~lioploum/linfo2401@lists.sr.ht"
You also need to configure you own email address. Firstly, the one that will appear as the author in the gitlog:
git config user.email "Ploum <ploum-PROJECT@mydomain.net>"
Then the email that will actually be used to send the patch (they could be different).
git config sendemail.from "Ploum <ploum-PROJECT@mydomain.net>"
All those steps should be done only once per repository.
Sending commits
Once you are satisfied with your commit, it’s time to send it to the project owner (the professor).
Now, we are ready to send the latest commit as a patch.
git send-email HEAD^
The HEAD^ is there to send the parent commit. If multiple commits are to be sent, you can use HEAD^^^ or HEAD~3. See git documentation for that.
That’s it! If your system was configured correctly, your patch was sent to the mailing-list!
From now on, each time you want to send a modification, all you have to do is :
git add MODIFIED_FILE git commit git send-email HEAD^
Once used to it, you could become incredibly efficient. It can even been used offline.
After your patch was accepted
Once your patch is accepted, it will be both local and upstream.
First do
git pull
You will be warned that your git branches have diverged. But, in reality, they diverged with the same patch on each side. You can simply resolve this with:
git rebase
The patch was refused
If, for some reason, your patch was refused, you will need to improve it then probably rebase it. This is explained on Offpunk website. See sections "Improving the patch" and "Rebasing the patch".