hi Ravindra, 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 ?
You do have to force-push after rebasing. I did write an e-mail about force-pushing where notifications are concerned. So let me revise my thoughts about it: * If you need to rebase, rebase. If you expect a contributor to look at your rebased PR, please comment to say that the PR has been updated because GitHub does not send email notifications for force pushes * If you don't *need* to rebase (i.e. there aren't any upstream patches you need), then it's OK to leave as is or keep pushing commits to the branch As we are not using Gerrit or similar code review tool, there is no squash-and-rebase requirement. The e-mail that I wrote was to let contributors know that there is an extra communication requirement when you force-push if you want your PR reviewed > > 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. > >> >
