Date: Tue, 5 Jan 2021 18:27:51 -0700 From: Warner Losh <imp@bsdimp.com> To: git@freebsd.org Subject: Git status update Message-ID: <CANCZdfpNL0CmLuczNZHueKZcbG_tuk56QC-2fj8SpDaQdFbmFA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
[ note: bcc'd to developers@FreeBSD.org, followup to git@] Greetings! I thought I'd give a brief update on the git migration, as well as clarify a few important points. Basic status: We've cut over to git. The source of truth is in git now. All commits go into git. Minor issues remain. A number of project processes depended on subversion. Most of these have been converted over, and new ones that are discovered are being converted when found. The git2svn replay has been delayed by illness, but should go live in a day or two. We will be replaying git commits to stable/11, stable/12 and the associated releng branches into that for the life of the branches. We will not be replaying into the head branch in subversion due to logistical issues. We've restarted mirroring to github, gitlab and other hosting services popular in Asia and Europe. The old mirror is retained on github as freebsd-legacy should you need it to migrate to the new mirror. The old mirror has stopped being updated. The git working group is looking at ways to enforce better dates in our workflow. Other projects have various processes in place to ensure better date sanity. While not strictly required, it can be helpful to have good temporal consistency in a way that's not a significant source of friction. Mark Johnson has a script to streamline phabricator and git integration. This allows one to create a review stream from a branch with multiple commits, with automated updating of the commit message, reviewed by, and updating the review itself after feedback is applied. You can find it at https://github.com/markjdb/scripts/blob/master/git-arc. Since this is new code, please take extra care in reviewing commits before pushing to help guard against bugs. Mark plans to commit the script under src/tools in the future. At this time, $FreeBSD$ tags should not be removed. This causes merge conflicts (has already caused them). New code that will never be MFC'd needn't have them. We've turned off enforcement that almost all files have them. However, since future stable/12 releases will be created from subversion, the tags must remain until EOL stable/12. We'll revisit this policy in the second half of 2021 after 13.0 and 12.3 are out to see how it's working out. But for now resist the urge to purge $FreeBSD$ tags from the src repo. In addition, large scale changes should be minimized for now. The dynamics of the git tool are different than the svn tool. There's a number of ways that other projects mitigate the hassles of large scale changes which the git team is looking into (anybody on git@ can help!). Until we can publish a set of recommendations (by the spring 2021), we'd ask that you defer sweeping changes that aren't strictly required. It's looking increasingly unlikely that got or gitup will be ready for 13.0 to be included in base. However, support for both as packages will likely be integrated into the tree since these tools are a bit different from GPL git(1). Please ensure that your Author Name is the same as your FreeBSD committer name. We've noticed a few instances where this wasn't the case so far. We want to make sure that anybody doing this is doing so intentionally and not accidentally. For the moment, a reminder email will be sent only when it's noticed. git log freebsd/main..main Please be mindful to use a single line summary for commits to make git log --oneline more useful. This should be followed by a blank line and then the rest of the commit message. Please take a moment to consider what's in this line and ask yourself if it's the most important information or not. If not, consider including it later in the commit message. MFCs should continue to be done as before (except using git cherry-pick, and maybe a rebase to squash), with one exception. Please consider adding (or reusing from the original commit) a single summary line that describes the MFC. We know it's on stable/12, so you don't need MFC in this line. We're writing up documentation on how to easily bring in pull requests from github, gitlab, etc. While straight forward, there's a number of fiddly details that you need to know and we're collecting all this info in one place. This will help land changes, but won't fix the project's long-standing 'somebody has to read the submissions' problem. We hope to also have some recommendations on that. Please see https://github.com/bsdimp/freebsd-git-docs for more details. Please note: I'm a couple days behind on pull requests. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpNL0CmLuczNZHueKZcbG_tuk56QC-2fj8SpDaQdFbmFA>