This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Holger Freyther holger at freyther.de> On 30 May 2016, at 18:56, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote: > > > On Mon, May 30, 2016 at 01:56:08PM +0200, Holger Freyther wrote: >> Can you elaborate? What are the goofy hacks? > > Before it was just git, now gerrit has its tag on near everything I do with the > code. I wish gerrit were less visible: > > - add gerrit remote > - two upstream repos to sync to (origin and gerrit) Do you know you can directly clone from ssh (one command)? You can also define one _remote_ and have different pull/push urls (okay would require post-clone work but maybe a script)? > - gitk shows every branch twice, once for each remote > - checking out a new branch is more complex; because of two remotes, one > needs to use the full 'git co -b <localname> --track <remote>/<name>' > instead of just 'git co -b <name>' > (I could probably work with just the gerrit remote, but then I wouldn't > see what our public master repositories are up to) > - commit id. I can't just clone, I have to do extra cycles for each clone. Okay, maybe a clone script? I assume you have one already? Yes, a small change in workflow but should be manageable? git config remote.origin.pushurl ssh://<GERRIT_HOST>:29418/<PROJECT_PATH>.git git config remote.origin.push refs/heads/*:refs/for/* git push origin imaginary script (typos..): $ cat git gerrit-clone git://git.osmocom.org/libosmocore #!/bin/sh set -e git clone $1 cd `basename $1 git` git config remote.origin.pushurl ... git config remote.origin.push.. scp .. .git/hooks echo "tada" yes, a change in muscle memory. When cloning you have to remember your gerrit username and that the repository was using gerrit. But from daily workflow it doesn't look that bad? Either way you have to make the mental decision if you push a wip branch or if you want to have review. > - access rules = obstructed access to branches = add 'users/' to all private branches > = we have scores of old branches now in a namespace we can't use anymore Then let's create one group like you did and allow everything for that group again? So one manual intervention and one can push to everything again. No issue with that. > - elaborate command line args instead of simple pushes > > Things just got so much more noisy on the git end. Can you try with the above options? Does it make more natural again? >> For patch-series: Either way, sending a 40 patches en-block is not well received. This wouldn't be any better with git dump-email. ;) > > It doesn't make much sense to split the IuPS dev into separate bits... > The branch makes sense as a whole. This is not a typical patch submission, > right? > > Subdividing would be artificial, but ok, can do, if that helps reviewing. Nobody will review 40 patches with full mental power. I didn't peek at the branch yet but I assume there are some general changes to the structure first, or adding Iu support first before using it? So start with something one can review within 30 minutes? > I've spent enough time on gerrit overhead. Do I have to understand this? At > least I would prefer not to, to use my resources for the tasks "piling up on my > desk" instead. We are stronger together. I certainly don't know everything about gerrit, I have not looked at which submit type makes the most sense for us, I picked one that looked reasonable (from allowing to pick patches of a series because we are picky). So try fast-forward only or merge or rebase if necessary. :) >> In osmo-sip-connector.git I changed from cherry-oick to always merge (probably fast-forward is closer to what we want in our change history) and pushed two changes. The last patch can be seen here https://gerrit.osmocom.org/#/c/127/1. > > yes, that kind of makes sense, but how does this work. I go to the website, > reconfigure the project, submit my branch so it comes in as <type> and then > configure the project back to what it was? :P > > What was your <type>, "always merge"? > Well, as I said, I hope I don't need to explore that right now... > > Please confirm that I should/can just push the first handful of IuPS changes to > for/master. Under Projects -> "openbsc.git" change it to "Rebase if necessary" and give it a small try (push a slightly outdated commit so we can see