On Monday, December 04, 2017 12:02:37 Ali Çehreli via Digitalmars-d-learn wrote: > On 12/04/2017 09:38 AM, Patrick Schluter wrote: > > So, avoid pull, look first what fetch does and if that is what you > > thought it would do, do the merge and be happy. > > +1 > > Paraphrasing someone I trust very much, "Never 'pull', always 'fetch -p' > and then rebase."
I use pull all the time, but it's always pulling master from upstream, and I never make any changes to my local master; all my changes go on branches. Using github or gitlab, I really don't have any other reason to pull or fetch, because the only place that I normally care about getting code from is upstream master. Any code being merged from someone else is merged into upstream master via github/gitlab, and my code is all done on separate branches that get pushed up to github/gitlab to be merged. With different workflows (like sharing work directly with someone rather than using github or gitlab), I could see reasons to be wary of pull, but in the typical workflow with github/gitlab, I really don't see any reason to be wary of it - not when the only time it's needed is to sync my local master with the main one on github/gitlab. - Jonathan M Davis
