On Tue, Apr 23, 2019 at 05:51:21PM -0700, we recorded a bogon-computron collision of the <curt.w...@gmail.com> flavor, containing: > Scenario: I have a topic branch I'm working on. A pull request or a direct > commit goes into upstream master. How should I update my topic branch? > > What I've been doing: > > Commit any changes to my topic branch. > git checkout master > git pull upstream master
Start getting less comfortable with "git pull" Use git fetch upstream git merge > git push origin master # To keep my Fork up-to-date Yes > git checkout <topic branch> Yes > git merge master Don't do that. git rebase master then git push --force origin <topic branch> > That procedure is what I think resulted in the merge commit earlier that > you didn't like in my later pull request off the topic branch. Improvements > to my procedure? I'd hate to wait for each of my pull requests to get > merged before I begin the next topic branch, plus that doesn't protect me > against somebody else's pull request getting merged or a direct commit to > upstream master: I still need a good method to update my local master, my > origin master, and my topic branch(es). You will have to rebase each time someone else pushes to master during the life of your pull request, until it gets merged. Not doing so makes a muddle of the history. You need to get comfortable with rebase and make peace with it. Used right, it is a powerful and important tool. Using merge for everything can lead to ugliness. -- Tom Russo KM5VY Tijeras, NM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] _______________________________________________ Xastir-dev mailing list Xastir-dev@lists.xastir.org http://xastir.org/mailman/listinfo/xastir-dev
