Date: Mon, 27 Apr 2015 18:10:15 -0700 From: Alfred Perlstein <bright@mu.org> To: David Chisnall <theraven@FreeBSD.org> Cc: freebsd-current Current <freebsd-current@freebsd.org>, ports <freebsd-ports@freebsd.org> Subject: Re: Merging GitHub Pull Requests into Subversion using git-svn Message-ID: <553EDDF7.6010302@mu.org> In-Reply-To: <29BE23C6-EBFE-40FB-91FC-C0E7CBFCFD45@FreeBSD.org> References: <CAG=rPVdNNsS42D4UVxmokzmxu3F4Kb7wYQnwQnn23g53zzX2Bg@mail.gmail.com> <29BE23C6-EBFE-40FB-91FC-C0E7CBFCFD45@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[[ reply private ]] On 4/25/15 12:30 AM, David Chisnall wrote: > On 23 Apr 2015, at 00:12, Craig Rodrigues <rodrigc@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?553EDDF7.6010302>