30 May
2016
30 May
'16
6:56 p.m.
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)
- 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.
- 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
- elaborate command line args instead of simple pushes
Things just got so much more noisy on the git end.
In fact reviewing has been more pleasant for me than
before (besides the pain of having to wrangle with Java and doing a FreeBSD port of buck
to build and debug it)
ok, that's a good thing.
My position + smiley means: I found it a hard process but it works the way it
is now; I'd have liked gerrit to be less visible in the daily workflows, but
whatever. If it's better for your reviewing, it's an improvement.
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.
Besides the smiley I think you could have been more
constructive, e.g you have admin rights and shell access to the system and I have already
pointed you to the "Submit Type" in the project settings. Did you have a look at
it to see if for your workflow we are using the wrong "type"?
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.
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.
~Neels