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. 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.
