gitk, etc By "messes up" I just mean that they are harder to read. Spaghetti lines of history versus nice linear history. On 09/30/2013 09:19 AM, Jason Greene wrote: > Which tools? > > On Sep 30, 2013, at 9:19 AM, Steve Ebersole <steven.ebersole(a)gmail.com&gt; wrote: > >> Merge over rebase of course messes up many history tools. >> >> I actually asked of GitHub support for the ability to rebase pull requests through the UI in much the same way we can merge already. I cannm let you know if/when i hear back. >> >> >> On Mon 30 Sep 2013 09:15:39 AM CDT, Jason Greene wrote: >>> On Sep 30, 2013, at 5:03 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; wrote: >>> >>>> Hello all, >>>> >>>> Is it intentional we have switched to 'Merge' commits for pull requests? >>> I'm exploring them as a way to speed up our merge process and provide better auditing. No decision yet. >>> >>>> e.g. >>>> >>>> https://github.com/wildfly/wildfly/commit/97ce5300f4277be023a112531b00dfa... >>>> >>>> Jason it is going to look like you have authored everything and in the >>>> future using annotate or browsing the history it is going to be more >>>> complex to identify why previous lines of code were written ;-) >>> That's not true. A merge commit links to the original author history. Github just displays the delta to be friendly. Git annotate also will show the original author sha1 and not the merge sha1. >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat >