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