I personally used all in the past (am, merge, apply-patch), depending on
the scenario of which one was easier to work with / apply (I a lot of times
I also need to check out the original branch and do some merge foo so I can
merge it cleanly into trunk).

I do prefer am since it doesn't result in a merge commit which makes the
history look slightly nicer.

Having said that, I'm fine with whatever approach is the easier to manage
for the person applying the patch as long as it meets this criteria:

- Preserve original commit author (preserve original commits as the are)
- Commit(s) are signed off by the person applying the changes
- We can easily add "Closed #PRNUMBER" or similar message to the commit(s)
message

Another option also is to try "git merge --no-commit" / "git merge
--squash", but we need to be careful with those so we don't rewrite history
(apache git repo actually doesn't allow pushing that, but it can still be
annoying).

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
>

Reply via email to