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