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

[Matěj Laitl]

On 10. 7. 2012 Edward Toroshchin wrote:
> 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".

Lucas' repo looks like it has no his own commits in master. Therefore I wanted 
to say: Shouldn't all his `git pull git://anongit.kde.org/amarok master` 
commands performed in his master branch have resulted in fast-forwards? (that 
don't create the merge commit so I therefore don't call them "merges")

E.g. `git push` without --rebase in master may still be correct if you don't 
have own commits so that it results in fast-forward, that's what I wanted to 
say.

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

Yes, pushing it to upstream master either through his master or directly.

> And, no, it won't make it tricky, because after a merge commit, pushing into
> master becomes a fast-forward operation. (...)

Bad wording, I wanted to say: wouldn't that push all those "Merge branch 
'master'" commits back to master, as it happened for example to Mamarok? [1] 
But now I realize that no, because upstream master is fully merged to his 
master.

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

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

Not in normal operation, but if you have merge conflicts and don't resolve them 
carefully, then yes. The point is that the second merge is somewhat prone to 
be resolved wrong in case of reverted commits, see 
https://github.com/strohel/failed-merge-plus-revert-showcase/network

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

Agreed.

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

Yes, thanks.

Regards,
	Matěj