Note that rebasing will mean you then later have to force-push into your work branches. And yes, work branches only, please. I strongly recommend against force-pushing to master. Or or pushing to master without a PR, either way.
On 16 February 2017 at 09:43, Rafał Harabień rafalh@reactos.org wrote:
You can change one config entry and you can forget about merging strategy:
git config --global pull.rebase true
You just have to force everyone to using it. Then simple git pull automatically rebases. We use it in work for all projects and history is linear.
W dniu 16.02.2017 o 09:37, Colin Finck pisze:
Am 16.02.2017 um 03:45 schrieb Zachary Gorden:
I've used both git and svn in work environments. If all you do is git pull and git push, you end up with lots of noise in the commit log with git tracking every single merge because you don't rebase.
To give a picture of what he is talking about:
http://fs5.directupload.net/images/170216/tfchxvni.png (random example repo on GitHub)
You see how parallel streams of history emerge with every new committer when just using git commit, git pull and git push. Commits in the list are not even in chronological order anymore.
Now what is the least painful way to avoid these automatic merges? We don't want to make life harder for any Git user..
- Colin
Ros-dev mailing listRos-dev@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Wolny od wirusów. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev