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.
