www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Git pragmatics
Date Fri, 06 Nov 2015 02:48:29 GMT
I’m posting to this list because this seems to be the forum to discuss recent interim changes
in git policy. I did not post to the "Git, history, protection, and other topics” thread
because it seems to be about technical implementation of the policy.

I wanted to share how the interim policy affects the Calcite project and the Drill project.
Hopefully we can find some short-term mitigation, and we can shape long term policy to accommodate
our use case.

Specifically, we use “scratch” branches for the many release candidates and screw ups
that occur while making a release (typos in the release notes, small changes to the web site,
fat-fingered URLs, mis-typed version numbers, forgotten entries in the KEYS file, etc.). We
don’t want to commit that mess to the permanent record.

To be clear, our final release candidate is based off of a commit that enters the permanent
record. Its sha is present in the release and the very same sha becomes part of the master
branch.

This might be a particular problem for those of us who use maven-release-plugin. It commits,
pushes and clones as part of its ordinary operation. If you are producing a release candidate
using maven-release-plugin, you HAVE to commit and push. We’d just rather that that commit
does not become permanent if the release candidate.

My proposal is that any branches whose names starts “temp-“ would be exempt from the new
rules.

A committer would be extremely unlikely to choose such a branch name accidentally; thus if
they created such a branch and did a force push or deleted it they would be intentionally
changing the way history looks, and since we trust committers, I believe we should allow such
behavior.

Julian


Mime
View raw message