Brad may provide a fuller answer, but in short it preserves more of history (when the commits were made, where that branched and merged back in), as well as allowing merges into multiple integration branches using the same commit objects. So using master and next, the only things that would differ if all branches were merged in both is the merge commits.<div>

<br></div><div>The problems we had in getting a topic branch out of your wrapping commits go away when topic branches are used, shared and later merged as Git recognizes them as the same commits. The CMake and Titan wikis contain more details on the motivations behind using it. We have only been using a small part of Git when requiring a linear workflow, and it would be nice to take fuller advantage.</div>

<div><br></div><div>Brad is writing up more details as we speak, and will make a broader announcement.</div><div><br></div><div>Thanks,</div><div><br></div><div>Marcus<br><br><div class="gmail_quote">On Wed, Jul 7, 2010 at 11:25 AM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I have what might be a silly question.  When a branch merge is done,<br>
it shows up simply as "Merge branch" in the logs, and a bit of digging<br>
is required to find out what has changed and why.<br>
<br>
Is there any advantage over doing a merge, as compared to pulling the<br>
changes from the branch, rebasing them, and pushing them?  For<br>
small changes, this would seem preferable over doing a merge, as least<br>
as far as the clarity of the logs is concerned.<br>
<font color="#888888"><br>
   David<br>
</font><div><div></div><div class="h5"><br>
<br>
On Wed, Jul 7, 2010 at 8:54 AM, Marcus D. Hanwell<br>
<<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>
> On Tue, Jul 6, 2010 at 1:13 PM, Marco Nolden <<a href="mailto:m.nolden@dkfz-heidelberg.de">m.nolden@dkfz-heidelberg.de</a>><br>
> wrote:<br>
>><br>
>> On 07/06/2010 06:11 PM, Marcus D. Hanwell wrote:<br>
>>><br>
>>> Sorry if I missed this one, the change looks reasonable and I can take a<br>
>>> look at it. It would be good to see improved unicode support too. It is<br>
>>> something that the ARB should probably be discussing, but it would be<br>
>>> great to involve the community as far as is possible.<br>
>>><br>
>>> Marcus<br>
>>><br>
>> Actually I revised it a bit, so the link is here:<br>
>><br>
>><br>
>> <a href="http://github.com/nolden/VTK/commit/9b76af72e6016fcd4a7b2e1a58edb77eb5549eef" target="_blank">http://github.com/nolden/VTK/commit/9b76af72e6016fcd4a7b2e1a58edb77eb5549eef</a><br>
>><br>
>> and the patch is attached.<br>
>><br>
> This is now merged, and was actually the first topic branch merged into VTK<br>
> using the staging repository we have been working on. I actually made a<br>
> second commit in that topic where I fixed the public API to use unsigned<br>
> char, and also use static_cast instead of the C style casts.<br>
> The commit prefix is normally BUG: rather than FIX: too, although this is<br>
> something else we need to make clear (are we requiring the log message<br>
> prefixes). Thanks for your patch, I encourage you to keep an eye on the<br>
> dashboards (although I will be doing that too).<br>
> Marcus<br>
</div></div><div class="im">> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
</div><div><div></div><div class="h5">> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
><br>
><br>
><br>
</div></div></blockquote></div><br></div>