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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
