Changes to our Git infrastructure

Thomas L├╝bking thomas.luebking at
Tue Dec 23 14:39:27 GMT 2014

Two things I like from recent grrit experience:
1. you can essentially use git to push the review (just as if you'd push to 
master, just a different branch)
2. The maintainer can just pick the patch, no actual need for the "ShipIt! 
-> Push" roundtrip which lead to dormant patches in the past. (Though, 
risking OT, this has less value w/o *any* CI)

As mentioned before a
3. thing that would be *really* cool was if one could annotate a repository 
directly and create a "review"/"do some" request w/o having to either clone 
the repo and create a local patch nor getting lost in bug reports where the 
main devs also have to lookup the actual code somewhere else (as I 
understood Albert, this would esp. be helpful for gardeners) - like one 
would enter quickgit, click a line number to create a comment (as in 
RB/gerrit review etc.) and that creates a request with a patch that adds 
some sort of special comment:

/* QUESTION by user luebking:
   are. you. insane?

/* REMARK by user luebking:
   afaiu m_foo can be reset by call bar() in which case this loop may run 

/* REMARK by user aacid
   can you please add a comment to this i18n ("i18nc("foo", "bar")")

I do not believe a mid-thing would be required then
(like using a webfrontend to upload a patch), since either you can git or 
you can't. If you can't, you cannot create a local patch (and imo. we 
should really not encourage ppl. to download tarballs)


More information about the kde-core-devel mailing list