RE: Git workflow question

-Original Message- From: Ravindra Pindikura Sent: Wednesday, January 30, 2019 8:52 PM To: dev@arrow.apache.org Subject: Re: Git workflow question Ok. Thanks, wes. > On Jan 30, 2019, at 8:43 PM, Wes McKinney wrote: > > hi Ravindra, > > On Wed, Jan 30, 2019 at 12:00

Re: Git workflow question

Ok. Thanks, wes. > On Jan 30, 2019, at 8:43 PM, Wes McKinney wrote: > > hi Ravindra, > > On Wed, Jan 30, 2019 at 12:00 AM Ravindra Pindikura > wrote: >> >> >> >> >>> On Jan 30, 2019, at 11:05 AM, Andy Grove wrote: >>> >>> Got it. Thanks for the clarification.

Re: Git workflow question

That's correct. Though I recommend putting this in the global .gitconfig because it gives you a more consistent Git experience. The default pull behavior will either do a fast-forward or a merge commit, but you never know which one it will be. On 30.01.19 21:16, Francois Saint-Jacques wrote:

Re: Git workflow question

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 wrote: > > That will be activated for all repositories, though, not only Arrow? > > Regards > > Antoine. > > > Le

Re: Git workflow question

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

Re: Git workflow question

hi Ravindra, On Wed, Jan 30, 2019 at 12:00 AM Ravindra Pindikura wrote: > > > > > > On Jan 30, 2019, at 11:05 AM, Andy Grove wrote: > > > > Got it. Thanks for the clarification. > > > > On Tue, Jan 29, 2019 at 10:30 PM Wes McKinney wrote: > > > >> hi Andy, > >> > >> yes, in this project I

Re: Git workflow question

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,

Re: Git workflow question

> On Jan 30, 2019, at 11:05 AM, Andy Grove wrote: > > Got it. Thanks for the clarification. > > On Tue, Jan 29, 2019 at 10:30 PM Wes McKinney wrote: > >> hi Andy, >> >> yes, in this project I recommend never using "git merge". Merge >> commits just make branches harder to maintain when

Re: Git workflow question

Got it. Thanks for the clarification. On Tue, Jan 29, 2019 at 10:30 PM Wes McKinney 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

Re: Git workflow question

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

Git workflow question

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