# CaROS
# Car Realtime Operating System.

A yocto base distro for DIY car radio

The CaROS specific software is found in meta-caros


## Description


## Setup

### Preliminaries

Install required packages:

- podman

### Get yocto-build
```shell
git clone git@git.larsniesen.de:caros/caros.git
```

### User Namespace Mapping

Ensure, that /etc/subgid and /etc/subuid contain corresponding
and sane entries for your account (podman run user).
If not you might need to run the following setup script (requires restart):
```shell
$ sudo ./dev/AddUserToSubgidAndSubuid.sh
```

## Start development build container

```shell
$ ./dev/bootstrap.sh [--deploy] [--sstate]
```

By adding the parameter --deploy, bootstraph.sh maps a deploy folder into the build container.
Built RPMs will be placed in this folder.

The parameter --sstate maps the build cache directory. This allows the cache to be preserved when the container
is closed thus significantly reducing build time.

You will end up in the yocto build container as user yocto e.g.:

```shell
[yocto@1453b5f0ab01 build]$
```



## Collaboration



### Working with branches

Every contributor should use his/her initials (eg. Max Mustermann uses 'mm') as the branch prefix.
After the prefix comes the issue ID and a short name describing the work.

The branch of Max Mustermann regarding the issue "#13 Integrate Fancy UI into the new web server"
should be named:

```
mm/13-integrate-new-web-ui
```

### Pull requests

The pull request is to be opened **after** testing the branch feature.
The exception to this are draft PRs

Before merging each PR needs to be reviewed from at least one other contributor

### Merging

Merges are to be done the following:

1. Update main.
```
$ git pull origin
```
2. Rebase main onto your feature branches.
    In your feature branch do:

```
$ git rebase origin/main
```

3. Test Again if the rebase broke something.
4. Squash your commits into one.
```
$ git rebase -i HEAD~<num of commits>
```
In the now open editor replace `pick` with `squash` on all of your commits except the first.
After that quit the editor and another editor should pop up. Now enter the new commit message.
The commit message should look like this:
```
<issue id>: Description
```
For the above example it would be:
```
13: Integrate the new web-UI to improve the experience for new users.
```
The Description should be **why** the commit was made and not **what** the commit does.

5. Now we add the hash at the start of the commit with:
```
git commit --amend -m "#13: Integrate the new web-UI to improve the experience for new users."
```
The amend flag lets you _change_ your last commit message. You have to enter your complete commit message but with a hash at the start.

6. Now force push your branch to the remote.

```
$ git push --force
```
7. Fast-forward merge on GitLab without merge commit.


For those who are not comfortable with git rebase please follow these steps.
It is still recommended to do the squashing on the terminal.


1. Update main.
```
$ git pull origin/main
```

2. Rebase main onto your feature branches.
    In your feature branch do:

```
$ git rebase origin/main
```

3. Test Again if the rebase broke something.

4. Now force push your branch to the remote.

```
$ git push --force
```

5. In the PR now fast-forward merge with squashing and without merge commit.