That will be activated for all repositories, though, not only Arrow?
Regards Antoine. Le 30/01/2019 à 19:48, Maximilian Michels a écrit : > With the no-merge-commits policy, you might find it helpful to add the > following > to the .gitconfig in your home folder: > > [pull] > rebase = true > > > That way you can use `git pull` without having to fear that it creates a > merge > commit. It does a `git fetch upstream branch && git rebase upstream/branch` > for > you automatically. > > -Max > > On 30.01.19 13:07, Tanya Schlusser wrote: >> This information might be useful to put on the 'contributing' page: >> https://cwiki.apache.org/confluence/display/ARROW/Contributing+to+Apache+Arrow >> I attempted to add it but don't have permission. It was one of my stumbling >> points too and I'm thankful someone else asked about it. >> >> On Wed, Jan 30, 2019 at 12:00 AM Ravindra Pindikura <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 ? >>> >>> 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. >>>>> >>> >>> >>
