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@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
