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> 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>
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