[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