This is also applicable to a per-repository basis by modifying the clone `.git/config` file instead of the global one in your home.
On Wed, Jan 30, 2019 at 1:49 PM Antoine Pitrou <anto...@python.org> wrote: > > 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. > >>>>> > >>> > >>> > >> >
