Date: Wed, 13 Jan 2021 21:07:29 -0700 From: Alan Somers <asomers@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-git@freebsd.org Subject: Re: Git status update Message-ID: <CAOtMX2jPZiOeRF-chSDc=LXixAe_rb%2B7eXjzmOtgLXwikGueYA@mail.gmail.com> In-Reply-To: <CANCZdfpNL0CmLuczNZHueKZcbG_tuk56QC-2fj8SpDaQdFbmFA@mail.gmail.com> References: <CANCZdfpNL0CmLuczNZHueKZcbG_tuk56QC-2fj8SpDaQdFbmFA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 5, 2021 at 6:28 PM Warner Losh <imp@bsdimp.com> wrote: > [ 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 > Is anybody working on https://ci.freebsd.org/ ? Its stable builders are working, but the head builders are still stuck on subversion. -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jPZiOeRF-chSDc=LXixAe_rb%2B7eXjzmOtgLXwikGueYA>