Ok. Thanks, wes.
> On Jan 30, 2019, at 8:43 PM, Wes McKinney <wesmck...@gmail.com> wrote:
>
> hi Ravindra,
>
> On Wed, Jan 30, 2019 at 12:00 AM Ravindra Pindikura <ravin...@dremio.com
> <mailto:ravin...@dremio.com>> wrote:
>>
>>
>>
>>
>>> On Jan 30, 2019, at 11:05 AM, Andy Grove <andygrov...@gmail.com> wrote:
>>>
>>> Got it. Thanks for the clarification.
>>>
>>> On Tue, Jan 29, 2019 at 10:30 PM Wes McKinney <wesmck...@gmail.com> wrote:
>>>
>>>> hi Andy,
>>>>
>>>> yes, in this project I recommend never using "git merge". Merge
>>>> commits just make branches harder to maintain when master is not using
>>>> "merge" for merging patches.
>>>>
>>>> It is semantically simpler in the case of conflicts with master to use
>>>> "git rebase -i" to combine your changes into a single commit, then
>>>> "git rebase master" and resolve the conflicts then.
>>
>> Here’s the workflow that I use :
>>
>> git fetch upstream
>> git log -> count my local commits, and remember it as ‘X'
>> git rebase -i HEAD~x
>> git rebase upstream/master
>> git push -f
>>
>>
>> I’m not able to avoid the ‘-f’ in the last step. But, Wes had recommended
>> that we avoid the force option. Is there a better way to do this ?
>
> You do have to force-push after rebasing.
>
> I did write an e-mail about force-pushing where notifications are
> concerned. So let me revise my thoughts about it:
>
> * If you need to rebase, rebase. If you expect a contributor to look
> at your rebased PR, please comment to say that the PR has been updated
> because GitHub does not send email notifications for force pushes
> * If you don't *need* to rebase (i.e. there aren't any upstream
> patches you need), then it's OK to leave as is or keep pushing commits
> to the branch
>
> As we are not using Gerrit or similar code review tool, there is no
> squash-and-rebase requirement. The e-mail that I wrote was to let
> contributors know that there is an extra communication requirement
> when you force-push if you want your PR reviewed
>
>>
>> Thanks & regards,
>> Ravindra,
>>
>>>>
>>>> A linear commit history, with all patches landing in master as single
>>>> commits, significantly eases downstream users who may be cherry
>>>> picking fixes into maintenance branches. The alternative -- trying to
>>>> sift the changes you want out of a tangled web of merge commits --
>>>> would be utter madness.
>>>>
>>>> - Wes
>>>>
>>>> On Tue, Jan 29, 2019 at 11:20 PM Andy Grove <andygrov...@gmail.com> wrote:
>>>>>
>>>>> I've been struggling a bit with the workflow and I think I see what I'm
>>>>> doing wrong now but wanted to confirm.
>>>>>
>>>>> I've been running the following to keep my fork up to date:
>>>>>
>>>>> git checkout master
>>>>> git fetch upstream
>>>>> git merge upstream/master
>>>>> git push origin
>>>>>
>>>>> And then to update my branch I have been doing:
>>>>>
>>>>> git checkout ARROW-nnnn
>>>>> git merge master
>>>>> git push origin
>>>>>
>>>>> This generally has worked but sometimes I seem to pick up random commits
>>>> on
>>>>> my branch.
>>>>>
>>>>> Reading the github fork workflow docs again it looks like I should have
>>>>> been running "git rebase master" instead of "git merge master" ?
>>>>>
>>>>> Is that the only mistake I'm making?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Andy.
