"hard time merging"? let me guess, "patch does not apply"? This is my
favourite error, so much so it's like a close family member.


On Fri, Oct 14, 2016 at 2:42 AM, Eric Johnson <erjoh...@apache.org> wrote:
> Yup, I kicked the can down the road. My next merge for #901 had the same
> issue.
>
> On Thu, Oct 13, 2016 at 8:19 AM, Eric Johnson <erjoh...@apache.org> wrote:
>
>> Not sure if this related, but I had a hard time merging #856 in this
>> morning.  I was following my normal procedure using git-am, updating
>> CHANGES.rst, then rebasing to squash into a single commit. Prior to rebase,
>> I'd see 065d1919d8cd1e651b92af6220b1408437b07563 in my git-log. During
>> rebase -i, I wouldn't see that commit in the list and if I proceeded with
>> my squash, that commit would get dropped.
>>
>> So, I either made the problem worse by not rebasing and pushing two
>> commits (one for #856 and one for updating changes), or I just kicked the
>> can down the road.  But maybe it'll be "fixed" for next committer?
>>
>> My git-foo isn't super strong and I'd welcome insight into how I could've
>> cleaned it up with git commands.
>>
>> On Wed, Oct 12, 2016 at 9:53 AM, Tomaz Muraus <to...@apache.org> wrote:
>>
>>> 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/065d1919d8cd1e651b
>>> 92af6220b140
>>> > 8437b07563
>>> >
>>> > Ant
>>> >
>>>
>>
>>

Reply via email to