All that follows are some thoughts that I want to write down before they are gone, but there may be a need for further discussion here.
Again regarding the hook: one supposedly simple way to design this with a local check is to have some way of extracting the supposed branch name from the commit message, then check that the information is consistent.
I think the commit messages will have to be the primary source of information. in a typical incoming set, we will have no branches involved because we generally only push branches to the github repository once they are integrated, at which point they are gone from git's perspective. The commit message is the only trace that remains. As a general design, I think we can treat the commit message as a source of metadata for hg-style branch information, and then the hooks need to check that the information is internally consistent and that it is consistent with any open branches that exist (including main).
For example, if the extracted branch name is issue111 and the commit belongs to an open branch (whatever "belongs to" means, but as a first approximation: there is an open branch such that ancestors(branch) \setminus ancestors(main) includes this commit, which is easy to express in git), then this branch should also be named issue111.
A commit on main should always have a main commit as its first parent. If it has a second parent, it should belong to an issueXYZ branch.
A commit on an issue branch can either have just one main parent (then it starts this branch), or a single parent on the same branch, or two parents: the first on the branch, the second on main (= the case where we merge back from main). Merging back from main is something many people consider icky. Perhaps we want to disallow it some time in the future (so this would require rebasing before merging to main in the future).
We have to decide whether we want to check that branch names follow our naming conventions.
I would also like to introduce and enforce an "at most two parents" rule (no octomerges). I think it makes tooling etc. much simpler. I think we already discussed this at some point, but it's not yet discussed on the wiki.
Perhaps this discussion does not belong to this issue. I guess this issue is about implementing the spec for github, not discussing it. I would like our wiki page to be precise enough that it can serve as a complete spec for the hook.
|