It's good to highlight the benefits of having merge commits, as I'm sure I'm not the only one that's sacrificed historic compatibility for cleanliness ...<div><br></div><div>Probably good to have this displayed prominently in the wiki, and maybe even start a github wiki for topics (like this) that exclusively affect development and developers and could facilitate contribution :)<br>
<br><div class="gmail_quote">On Thu, Jun 7, 2012 at 8:48 AM, Willem Jan Palenstijn <span dir="ltr"><<a href="mailto:wjp@usecode.org" target="_blank">wjp@usecode.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
After some IRC discussion about the merits of rebasing and merging in git<br>
recently, I've written up some notes/suggestions on the topic below.<br>
<br>
Any comments? Additional good advice? Different opinions?<br>
<br>
<br>
Something I'd like to discuss further before even starting to write it down:<br>
Are there any specific cases where we should encourage squashing before<br>
merging? I'm thinking of things like accidentally committed files/directories,<br>
mass renames, unintended broken builds, savegame incompatibility, commits<br>
immediately followed by typo fixes/minor bugfixes, ...<br>
<br>
<br>
<br>
-Willem Jan<br>
<br>
<br>
<br>
----<br>
<br>
One line summary: Don't rebase branches just to avoid merges.<br>
<br>
This applies both during development of a topic branch and when pushing it to<br>
master, including for github pull requests.<br>
<br>
While rebasing does make a branch's history seem cleaner, it requires<br>
significant effort to ensure rebasing doesn't break the history. Some forms of<br>
broken history are easily detected because they break the build, but others are<br>
much more subtle.<br>
<br>
Also, merge commits are a useful place to put a summary of changes introduced<br>
in a set of commits. You should even consider adding a merge commit for this<br>
purpose even if the merge would otherwise not need one. A particular case where<br>
this could be valuable is if for some (preferably very good) reason you<br>
temporarily need to break the build: follow up the "broken build" commits with<br>
a merge commit as a clear way to mark them.<br>
<br>
There are of course cases where a rebase does indeed clean things up, and for<br>
small sets of changes this is definitely worth considering.<br>
<br>
In general, apply common sense. This document should only be considered a<br>
guideline, since for any rule there will be exceptions. Feel free to ask on the<br>
mailing list or on IRC at any time about what would be appropriate in any<br>
specific case.<br>
<br>
<br>
Historical context:<br>
<br>
When we switched from subversion to git, we initially had a preference to use<br>
rebasing to avoid merge commits, because those felt unnecessary or ugly. After<br>
working with git for a while as a project, the disadvantages have started to<br>
become more clear, to the point where we now generally prefer merges.<br>
<br>
<br>
<br>
<br>
<br>
------------------------------------------------------------------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<br>
will include endpoint security, mobile security and the latest in malware<br>
threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>
_______________________________________________<br>
Scummvm-devel mailing list<br>
<a href="mailto:Scummvm-devel@lists.sourceforge.net">Scummvm-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/scummvm-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/scummvm-devel</a><br>
</blockquote></div><br></div>