14 Sep
2017
14 Sep
'17
3:23 p.m.
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
