Am 01.06.2011 05:02, schrieb Peter Stuge:
Patrick Georgi wrote:
I'm officially sick and tired of patchwork. Or from losing patches to the mailing list.
Hear hear!
Mail is for spam-delivery, an ancient tool from a distant past ;-)
No, seriously - we have 100+ unhandled patches on patchwork, many of them iterations on a single topic that must be cleaned up manually (because the scripts can't).
If patches bitrot in gerrit, at least they're already build tested, and iterations are grouped together automatically. Which means less work for the poor soul trying to clean up.
Enter gerrit: A web tool to push git commits to, have them reviewed, with proper handling of updated patches. Automatic support for dependencies between commits (by default it assumes that ancestry means dependency). An automated gatekeeper to the repository.
Sounds even better! Does updated patches mean rebase?
rebase, modifications, ... essentially, it's possible to track a single issue and its patches at a single location.
So far there has been no way at all to push git commits to the main repo and I really like the look of this setup so if we want to start getting commits also via git then I think it makes perfect sense.
It's a special workflow, but for git there doesn't seem to be a default workflow anyway. Specifically, there's no way to push to master directly. Instead: - commits are pushed to gerrit (by normal "git push" and a commit-message hook that adds a Change-Id entry) - commits are build tested by jenkins automatically, which registers its vote with gerrit - commits are reviewed by other developers - sufficient positive review count -> commits are pushed to mainline by gerrit
Maybe the svn repo can (and should) stay primary repo a while longer still, but that would require a magic post-receive git hook to transplant received commits into the svn repo, which comes with lots of fun potential synchronization issues.
We'd need bidirectional bridging that doesn't always break...
It may also be just as well to simply rip off the svn bandaid once and for all.
... so I'd prefer that.
Some contributors may experience issues with firewalls when switching from svn to ssh, but meanwhile it would always be possible to send patches generated by git via email. (There is even a git send-email command that automates the process.)
People generally had a problem with accessing svn:// URLs already, so we provided a http[s] read-only copy of the repo. I guess we can do similar with a read-only git repo.
Patrick