4 ms·
So what? If the crowd doesn't want to use it, what of it? You only rebase on your own changes before you push the patches.
by chris_wot 4y ago
So what? If the crowd doesn't want to use it, what of it? You only rebase on your own changes before you push the patches.
- OJFord 4y agoWell my suggestion really was just that it's pointless to write about, because you won't convert anyone. (Not '..and you should be doing xyz because that will convert them and that's what we want'.) But to answer your actual question, there are various ways in which what others on a team do affects you: - CI building 'merge branch master' all the time on master, because of merge-pulling upstream changes after committing - spaghetti merge feature branches (that you might be reviewing, working jointly on, or as below) - git log, blame, etc.
- chris_wot 4y agoYeah, rebasing in master is a huge no-no. LWN has a great article: https://lwn.net/Articles/328436/ https://lwn.net/Articles/328436/ Linus Torvalds explained it best: https://lwn.net/Articles/328438/ https://lwn.net/Articles/328438/
- OJFord 4y agoIf you have local, un-pushed commits 'on' master, and there are upstream changes to master that you lack locally, there is absolutely nothing wrong with pull.rebase, i.e. rebasing your local changes on the upstream ones before you push. Beats the hell out of: * deadbeef (master) Merge branch 'master' of upstream |\ | * feedbeef A proper commit message from upstream * | deafbeef A proper commit message of the actual change |/ which not only hides the real commit message in CI, but also flips around the history so master's snaking around between upstream's path and the person not pull.rebase-ing's path.