3 ms·

> you can see that someone messed up and thought they rebased before merging but actually didn't we use a pre-receive hook which checks that the "oldest ancest

> you can see that someone messed up and thought they rebased before merging but actually didn't we use a pre-receive hook which checks that the "oldest ancestor" between the branch being pushed to (i.e. current master's SHA) and the branch being pushed (i.e. the tip of what is to become the new branch) is actually the current master's sha; else, the push is rejected with "Rebase a merged branch before merging it into master". "oldest ancestor" being: * take git rev-list --boundary $current_master_sha..$new_sha * get the last line matching ^- and remove the ^- * that should be $current_master_sha; if not, error.

Joky 8y ago
> we use a pre-receive hook But in the context of this discussion, LLVM is moving to GitHub and there is no possibility of custom pre-receive hook there as far as I know.
- avar 8y ago
  As discussed in the linked E-Mail thread they're either talking about using GitHub as a publishing platform for something where they do have custom hooks, or making everything go through GitHub pull requests. Using either of those methods they can enforce this. E.g. if they go through PRs just write a script that e.g. grabs the refs for the PR, rebases (and --no-ff merges, depending) the commits there, pushes them to master, and closes the PR as merged. The user running that script would be the only one allowed to commit to "master", and would use its own scripted method of integrating them, instead of clicking "Merge" in the GitLab UI.
  - Joky 8y ago
    LLVM allows direct push to master from its contributor. If we were to go through pull-requests, we wouldn't need anything as GitHub has this setting built-in: https://help.github.com/articles/configuring-commit-rebasing-for-pull-requests/ https://help.github.com/articles/configuring-commit-rebasing...
avar 8y ago
Note that this will allow someone to push a history where you have a deeply nested merge mess of some sort all based off the current upstream master. That's not very likely, but in the interest of sanity and avoiding history complexity (which is the whole point) perhaps it's better to check: 1. That what's being pushed has either zero or one merge commit. Use "git rev-list --min-parents=2". If it's zero you don't need to check anything else (I'm assuming you're checking non-fast-forwards already). 2. If that one merge commit is there, unpack its parents and check that one side of it is strictly ahead of the current master. You can do this with "git merge-base --is-ancestor A B". 3. For consistency, validate that the LHS or RHS of the merge is the existing master, depending on your taste. Usually you'd want it to be the LHS. Only this way will you guarantee that you have a history without nesting in "git log --oneline --graph", if that's what you're after, which I suspect people who'd like a hook like this actually want, not what you've outlined.

Joky 8y ago

> we use a pre-receive hook But in the context of this discussion, LLVM is moving to GitHub and there is no possibility of custom pre-receive hook there as far as I know.

avar 8y ago
As discussed in the linked E-Mail thread they're either talking about using GitHub as a publishing platform for something where they do have custom hooks, or making everything go through GitHub pull requests. Using either of those methods they can enforce this. E.g. if they go through PRs just write a script that e.g. grabs the refs for the PR, rebases (and --no-ff merges, depending) the commits there, pushes them to master, and closes the PR as merged. The user running that script would be the only one allowed to commit to "master", and would use its own scripted method of integrating them, instead of clicking "Merge" in the GitLab UI.
- Joky 8y ago
  LLVM allows direct push to master from its contributor. If we were to go through pull-requests, we wouldn't need anything as GitHub has this setting built-in: https://help.github.com/articles/configuring-commit-rebasing-for-pull-requests/ https://help.github.com/articles/configuring-commit-rebasing...

avar 8y ago

Note that this will allow someone to push a history where you have a deeply nested merge mess of some sort all based off the current upstream master. That's not very likely, but in the interest of sanity and avoiding history complexity (which is the whole point) perhaps it's better to check: 1. That what's being pushed has either zero or one merge commit. Use "git rev-list --min-parents=2". If it's zero you don't need to check anything else (I'm assuming you're checking non-fast-forwards already). 2. If that one merge commit is there, unpack its parents and check that one side of it is strictly ahead of the current master. You can do this with "git merge-base --is-ancestor A B". 3. For consistency, validate that the LHS or RHS of the merge is the existing master, depending on your taste. Usually you'd want it to be the LHS. Only this way will you guarantee that you have a history without nesting in "git log --oneline --graph", if that's what you're after, which I suspect people who'd like a hook like this actually want, not what you've outlined.