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

[Edward Toroshchin]

G'day,

On Tue, Jul 10, 2012 at 01:25:59PM +0200, Matěj Laitl wrote:
> 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?

"Merge" and "fast-forward" are not antonyms. What you (probably) wanted
to say here was "rebases". If you wanted to say "fast-forward", you'd
better read more about merges, rebases, and fast-forwards; or just ask
me in IRC, I'll be glad to clarify.

> My only fear is that this will make merging your tomahawk branch into
> master tricky.

What you meant here was probably "pushing" your branch into master. And,
no, it won't make it tricky, because after a merge commit, pushing into
master becomes a fast-forward operation (unless someone managed to push
something else, why you were at it, but it's generally unsolveable in
centralized repository infrastructure).

>  * 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.

No it can't. Indeed, it creates a messy "loopy" history, which is
generally frowned upon, because it's a structure without semantics. But
it does not by itself lead to any "strange" things, including
reintroducting reverted commits.

I agree that rebasing a long-lived feature branch should be preferred to
merging upstream master repeatedly into it.

I would like to add also, that unless you depend on some new features
being added to upstream master (like API changes, or bugfixes), you
don't need to rebase often, or even at all.

For example, Phalgun is working in his own directory on his Nepomuk
collection. I have advised him not to rebase or merge at all, because he
won't get any conflicts at the end of the development, and he does not
require anything bleeding edge from amarok master.

>  * 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.

I should clarify here, that Matěj was referring to "merge and push" at
the end of your feature branch life cycle (i.e. when your subproject is
complete), and not something you do repeatedly during development.


Cheers,
-- 
Edward "Hades" Toroshchin
dr_lepper on irc.freenode.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20120710/35e26e4e/attachment.sig>