Hi Martin,

Is there any guidline for the interplay of commits wich are intended to enrich 'genodelabs/genode' and issues at 'genodelabs'. I wonder if i should create issues for all commits i.e. and if my commit messages should always rely on an issue.

I am glad that you bring up this issue. I have seen a lot of activity in your fork but I am yet a bit hesitant to merge your stuff into genodelabs/genode because of the sheer quantity of commits. For me it is hard to distinguish the commits that are individual topics (i.e., the base-host PDBG suff) and ready to merge from those, that are just your line of work within base-hw. I would need to manually go through all of them.

Hence, I propose to have one branch per issue. For example, for the 'base-host' improvements, you could create an issue describing why this work is important. Then create a branch (of the state of genodelabs/master) and add the commits related to this issue to the branch. This would ease my work with identifying the parts of your work that are ready to merge.

As for the continuous work on base-hw on your private branch, feel free to commit as you like. For example, your commit sequence could look like

"Implemented A" "Discarded a part of A because it was a bad idea" "Fixed spelling in comment"

Just prior merging, you should clean up your history into meaningful commits using 'git rebase -i'. The refined history will then end up in just a few commits. For the example above, all three commits should be merged into a single commit "Feature A" as the intermediate (and potentially bugged) revisions are not useful to have in genodelabs/main.

Cheers Norman