[Tomahawk Integration] GSoC Report (plus: RFC on git work-flow guideline)

[Matěj Laitl]

On 9. 7. 2012 Lucas Lira Gomes wrote:
> Hi everyone,

Hi Lucas,

> My amarok repo:
> http://quickgit.kde.org/index.php?p=clones%2Famarok%2Fgomes%2Fmaskmaster-ama
> rok.git&a=summary (tomahawk
> branch)

I've checked above repo and the master branch there is polluted with many 
Merge branch 'master' of git://anongit.kde.org/amarok commits. Shouldn't all 
these be fast-forwards? My only fear is that this will make merging your 
tomahawk branch into master tricky. I would advise having the master a carbon-
copy of Amarok upstream master.

The history of tomahawk branch itself looks fine.

To all developers, contributors, GSoCers, SoKers, I think we should adopt 
following git work-flow rules:
 * upstream master branch is never _merged_ _to_ feature branches/personal 
clones etc. If you want to have new commits, _rebase_ your feature 
branch/clone on top of upstream master. (e.g. `git pull --ff-only`, `git pull 
--rebase` etc.)
   ^^^ why? Because if such feature branch is merged into master, it can 
result in strange things including silently reintroducing reverted commits in 
the worst case and pollutes the history in the best case.
 * merging feature branches to upstream master is fine and should be preferred 
over squashing the commits or making it a fast-forward. Ideally, a list of 
merged commits is embedded in the merge-commit, so the command should look 
like: `git merge --no-ff --log feature-branch`. See [1] for example.
   ^^^ why? Because tools like git bisect and git blame depend on fine-grained 
commit history. git blame (or its KDevelop integration) is very useful for 
"why does this code line exist?" type of questions, you should use it, really. 
Creating merge-commits makes the history more organized and allows for 
reverting or diff-ing whole merges.

[1] 
http://quickgit.kde.org/index.php?p=amarok.git&a=commit&h=8d8404a9a95d3a49026eac972783f66061675e53

	Matěj