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 list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



Wolny od wirusów. www.avast.com

_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev