[Development] gerrit : pointers to use it cleverly/efficiently?

René J. V. Bertin rjvbertin at gmail.com
Fri Apr 1 11:42:32 CEST 2016


Welbourne Edward wrote:

> Well, any way of pushing is subject to that, yes.
> The new commit can't arrive without all of its ancestors, that's a
> feature of the git object model; and each of those ancestors has a
> Commit-Id, so necessarily triggers an update to its review.
> 
> Not that this doesn't irritate me every time I trip over it ...

...

> 
>> Unless there is a magic I'm not aware of, the
>> temporary-branch-plus-cherry-pick is the only way to push a single
>> commit among a list of many.
> 
> That's probably inescapable, yes.

I haven't tried to "rebase" my mental models and parse everything that's been 
said, but it sure sounds a whole lot like my own gripes with gerrit's overhead 
for submitting a few simple(r) patches. Especially if you also want to maintain 
those for local builds on multiple hosts against a specific source version (think 
a file in debian/patches) rather than somehow exporting your local working copy 
with its subsequent commits to all those hosts.

Thinking aloud:

I may be old fashioned (aka a dinosaur) in this aspect, but I prefer seeing 
exactly which hunks of a set of changes (patchfile) require attention when 
updating, say, a patch conceived against v5.i to apply against v5.j. The larger 
the patch, the bigger the chance IMHO that you miss something crucial when 
automatic rebasing succeeds for all but a few hunks. I've seen it often enough 
for instance that a patch adds a line somewhere, and still applies when that 
change was already incorporated "upstream". That can lead to subtle regressions, 
depending on whether repeating the line (possibly multiple times) has side-
effects or not.

I suppose gerrit has the advantage (if advantage it is) of including the final 
commit message in the review process from the get go. It probably also means 
that final commit is done as a merge from the gerrit repo into the main repo 
rather than as a "manual" direct commit by the submitter - and I can see how 
that's an advantage. But it seems the one doesn't exclude the other.

Thiago mentioned how they cannot replace/upgrade gerrit for some reason. What 
might be possible is to maintain it only as a gateway for patches that have 
gotten the green light on whatever other review system that's deemed more 
powerful/modern/convenient to use.
FWIW, KDE is apparently transitioning to Phabricator - I don't yet have any 
experience with it so cannot comment on it one way or another.

> $ git checkout -b tmp $currentPSsha1^
> $ git cherry-pick $newcommit
> $ git push gerrit HEAD:refs/for/$branch

That really looks like updating your change set against a new remote version, 
and then uploading that new version for review ...

R.




More information about the Development mailing list