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

[Matěj Laitl]

On 10. 7. 2012 Edward Toroshchin wrote:
> On Tue, Jul 10, 2012 at 03:01:06PM +0200, Matěj Laitl wrote:
> > 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.
> 
> I see. There is actually commit bedfbae3ed20b0676482f601cef0607f2325586a
> there.

Good, we've just prevented push of accidental commit to master.

> I presume Lucas expected his branch "master" to be, as you put it, a
> carbon-copy, but forgot this one commit. It made all his pull
> operations merges.
> 
> I recommend using the options "--ff-only" and/or "--rebase" more often
> to avoid Git doing unwanted things.

Exactly.

> > 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
> 
> This problem can of course be avoided by getting rid of frequent merges.
> 
> It is however not a direct consequence of these merges, but rather a
> consequence of sloppy merge conflict resolution. If you used a proper
> mergetool or at least had set merge.conflictstyle = diff3, you would
> know that this "b" line had been deleted in master, and you should not
> leave it in your merged code.

Agreed. And hey, I didn't know about merge.conflictstyle, that'll make my life 
much easier, thanks!

	Matěj