Guideline for commits and issues

[Norman Feske]

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