I vote for recommending devs to use pull requests, and to make it a semi-strict policy that devs who push directly to master should ALWAYS make sure to pull and rebase before pushing.
I myself intend on almost exclusively contribute through pull requests. This means: 1. I'll push to my own fork, and work backed by the fork 2. When I'm done doing something, I will use the pull request feature, rather than "git push upstream/master" 3. If the changes are non-trivial, I'll ask for a second opinion from some other developer 4. I'll push "merge with rebase" myself, but only when I feel the changes are "sufficiently approved" I would vote for using such a workflow as a primary way of contributing, since it avoids all sorts of issues, and has the added benefit of the automatic "merge with rebase". On 14 September 2017 at 17:23, Colin Finck <co...@reactos.org> wrote: > Hi all! > > After playing around with GitHub's features in > https://github.com/colinfinck/sandbox for the last few days, it turns > out that its server-side settings hardly prevent repository mess. > > Although I have set master to be a "protected branch" and enabled the > option "Require branches to be up to date before merging", it allows me > to push just everything that doesn't rewrite history. This includes any > kind of merge commits, even the nasty automatic merges that occur when > you commit to your outdated local master and then do the requested "git > pull" before pushing. > GitHub Staff confirmed to me that GitHub has no way of enforcing a > rebase-only workflow. For a self-hosted Git, a simple pre-receive hook > like https://stackoverflow.com/a/5493549 would do the trick. > > The only other option GitHub offers is requiring each commit to go to a > branch. Changes to master can only happen through an approved Pull > Request then. This would drastically change our workflow though, and I > don't think we want this additional burden for every minor change. > > Before we now reverse our decision for a GitHub master repo, let's > verify that a self-hosted Git repo with an enforced rebase-only workflow > is really what we want: > > - It would ensure a linear history in the "master" branch, just like > WINE has. If you sort by "Commit Date" instead of "Author Date", the > history would even be chronological. > - When contributing changes from a branch back to "master" using "git > rebase", every single commit is reapplied with a new hash. Except for > the author dates, these commits have no link to the original branch. > - Without GitHub as the master repo, we would lose the ability to merge > Pull Requests directly from the website. That would sooner or later turn > the entire Pull Request feature of GitHub useless for us. > Contrary to what people told me, GitHub doesn't detect when you merge > the Pull Request locally and push these changes back to GitHub. > > > On the other hand, what would an unrestricted GitHub provide us: > > - Discussing, improving, and later merging Pull Requests directly on the > website. Merging, squash merging, and rebase merging is supported. Not > just for our own branches, but also for forks of the ReactOS repo. > - Our history graph in the "master" branch will inevitably become a > stream of parallel lines, making it harder to follow the history > chronologically. Worst-case example is the Linux kernel: > http://fs5.directupload.net/images/170914/h5pddxx7.png > (ok, admittedly gitk renders this graph a bit nicer) > > Allowing merges used to be an even bigger problem when we still wanted a > linear history to replicate SVN revision numbers. But we now replaced > revision numbers by the output of "git describe". So maybe merge commits > are ok now? > At least, we should be able to prevent automatic merge commits by > instructing every committer to use "git fetch && git rebase origin" > instead of "git pull" when syncing with the server. A nicely written and > illustrated (Tortoise)Git guide on the Wiki should do the job :) > > > I tend to favor the second option right now and allow merges, but I > definitely need more input on this from you. > > > Best regards, > > Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
