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

[Bart Cerneels]

This command is mandatory for all amarok developers:
git config branch.master.rebase true

the result of this is that all "git pull" commands will do a rebase
rather then a merge. Your local commits will be rewritten (parented to
origin/master). The prevents the git log to become unreadable because
of all the merge commits.
Merge commits will only show on real branch merges. But since we don't
use much branches in the repository on KDE it's should be an uncommon
thing.

I'll add a file to HACKING explaining this.

On Tue, Jul 10, 2012 at 1:25 PM, Matěj Laitl <matej at laitl.cz> wrote:
> 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
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel