From owner-freebsd-current@FreeBSD.ORG Tue Apr 28 01:10:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB03585B; Tue, 28 Apr 2015 01:10:12 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id C91DE1867; Tue, 28 Apr 2015 01:10:12 +0000 (UTC) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 745BB341F86B; Mon, 27 Apr 2015 18:10:10 -0700 (PDT) Message-ID: <553EDDF7.6010302@mu.org> Date: Mon, 27 Apr 2015 18:10:15 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: David Chisnall CC: freebsd-current Current , ports Subject: Re: Merging GitHub Pull Requests into Subversion using git-svn References: <29BE23C6-EBFE-40FB-91FC-C0E7CBFCFD45@FreeBSD.org> In-Reply-To: <29BE23C6-EBFE-40FB-91FC-C0E7CBFCFD45@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 01:10:13 -0000 [[ reply private ]] On 4/25/15 12:30 AM, David Chisnall wrote: > On 23 Apr 2015, at 00:12, Craig Rodrigues wrote: >> While not as smooth as clicking a merge button in GitHub, >> this is a valid way to accept patches submitted via GitHub pull requests, >> and integrate them in our FreeBSD Subversion repo. > The merge button on GitHub does the wrong thing anyway (merges without fast-forward, so you end up with a tangled history), so (after the initial setup) the steps that I use for merging pull requests from GitHub projects are very similar (locally pull the branch with fast-fordward, test, push). Not to bikeshed this, but you really almost never want a fast-forward commit. The reason is that it becomes challenging to git-bisect things to sort out where a bad commit was. In addition then the merge is actually one "atomic" commit. Getting over viewing "merge commits" as "messy" was the final hurdle I faced going towards git-nirvana. -Alfred