I agree that git-am can be a pain.
What I like about using it though, is that history is more forthcoming
about original author versus us showing up all the time.
"""
commit 065d1919d8cd1e651b92af6220b1408437b07563
Merge: 4897933 0d1a9d2
Author: Anthony Shaw <anthonys...@apache.org>
Date: Wed Oct 12 09:41:47 2016 +1100
Merge branch 'libcloud-889' into trunk
Closes #889
"""
Versus an older git-am commit entry,
"""
commit f5ff0cfb080b767b542e9deec5ecc34dedcb4f0c
Author: Fahri Cihan Demirci <fem...@users.noreply.github.com>
Date: Sun Oct 9 02:15:10 2016 -0400
LIBCLOUD-858: Fix Listing Libvirt Nodes with Python 3
Closes #894
"""
Plus in the GitHub web UI, you can see original authors more clearly
[scroll down to look at these same two commits,
https://github.com/apache/libcloud/commits/trunk]
If there's a way to preserve that, I'm all for stepping away from git-am.
On Tue, Oct 11, 2016 at 3:49 PM, anthony shaw <anthony.p.s...@gmail.com>
wrote:
> Hi,
>
> Our PR process (applies to committers but anyone else is welcome to
> weigh in) says to download the patch file from GitHub and apply the
> patch using the `git am` command.
>
> I find git am to be so fragile, typically I use the --3way flag to
> help it try and resolve conflicts but normally is just stumbles on the
> slightest issue.
>
> The new process I've been using is :
>
> git fetch https://github.com/<remote user>/libcloud
> <remote-branch>:github-<pr>
> git merge <github-pr>
>
> .. edit merge message to included Closes #PR
>
> Then push to apache trunk.
>
> An obvious advantage is that in GitHub the PRs show as merged.
> https://github.com/apache/libcloud/pull/899
>
> The merge tool in git (instead of the patch) is so much more reliable.
>
> What do people think of this approach? Here is an example -
> https://github.com/apache/libcloud/commit/065d1919d8cd1e651b92af6220b140
> 8437b07563
>
> Ant
>
