Does gerrit support review for merge commits

[Anatol Pomazau]

Hi

Here is my situation. In my repository I have a fork of third-party project. And my changes reviewed via Gerrit as usual.

Periodically I need to merge a large set of third-party patches (let's imaging original project releases a new version) and I want to pull/merge it to my repository. I would like to create a merge commit for this release, put it to Gerrit, let people review/approve it. At the same time I do *not* want to create CL's for all 1000 commits from original project. I do not want to review all small commit I just want to review one merge commit.

Is it possible to push to Gerrit a merge commit without creating CL's for its parents?

[Alex Blewitt]

No; if you push it, it will create lots of little reviews. And in any case the Gerrit review on the merge commit will not show you the changes you expect: it will show (in essence) those files that had conflicts that you fixed and not "this is he set of things that are changed by merging this whole branch in". 

Alex

Sent from my iPhat 6

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Darragh Bailey]

If you push up a branch containing all of the upstream changes directly, and then submit a review of the merge between it and your branch carrying the modifications you'll only get a review of the merge commit.

We do that in work by having a special CI job that has push privileges to a particular set of branches to bypass reviews for code from the upstream project.

However we don't use a normal merge, and have a slightly different workflow which you may want to consider if you're expecting that you'll constantly be tracking the upstream project but needing to push on with local changes applied.

We also always want the possibility to re review the changes we carry in the context of the latest upstream, and use a tool called git-upstream (I'm the author), to rebase the local changes onto the upstream and then perform a special merge to discard what was previous on master in favour of what is coming from upstream+our patches.

See https://github.com/stackforge/git-upstream for more info.

So yes, you can push the upstream directly to a branch in your gerrit repo bypassing review, and then create a merge commit, but you may find that difficult to review and also less clear over time as to where changes came from. See evil merges on stackforge about that.

---
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool" - unknown

[Matthias Sohn]

we solve this problem for some open source projects we have forked internally in the following way:

we have a cron job running on the host where Gerrit runs which periodically fetches all changes

from the upstream open source project to separate branches mirroring all changes arriving in the

upstream repository. We define a dedicated remote for that.

e.g. in order to mirror Gerrit source we use the following configuration in the bare repository

hosting our Gerrit fork

[remote "google"]

url = https://gerrit.googlesource.com/gerrit

fetch = +refs/heads/*:refs/heads/google/*

and the cron job runs

$ git fetch -f

once every hour

When we want to merge changes from upstream to our internal fork we merge the corresponding

open source branch into the branch in our fork which should be updated and push this merge commit

for review. Since the changes being merged were already replicated behind Gerrit's back no reviews

are created for these changes but only for the merge commit which merges the upstream changes

into our internal branch.

-Matthias

[Magnus Bäck]

On Wednesday, September 23, 2015 at 14:35 CEST,

As long as the new upstream commits are known to Gerrit (i.e. they exist
in the git and are reachable from somewhere) you can merge an upstream
to your branch and push the resulting merge commit for review. This will
create a single change.

Unfortunately I don't recall whether the merge commit is displayed in
Gerrit in a useful way. It used to be displayed as an empty commit so
to actually review the contents of the merge you'd have to download the
change and inspect it with local tools. This might have changed in
recent years though. I know it has been discussed in the community and
I think I've seen a patch for it.

--
Magnus Bäck | Software Engineer, Firmware Platform Tools
magnu...@axis.com | Axis Communications

[Anatol Pomazau]

Hi

Thanks everyone for replies. I am trying to do this "push upstream to a branch" trick. I do not have access to the server's storage so I can use 'git push" only.

I fetched upstream locally, then pushed FETCH_HEAD to a refs/sandbox/$USERNAME/upstream branch. FETCH_HEAD and the sanbdox branches are correctly point to upstream changes.

I created a merge commit 'git merge FETCH_HEAD'. It created a merge commit:

$ git show

commit 3b3869a3b38a520d9a14e1c032bae739b9a551a0

Merge: 6e416f4 02fddc8

Author: Anatol Pomazau <ana...@google.com>

Date:   Fri Oct 2 10:23:00 2015 -0700

    Merge remote-tracking branch 'upstream/release-6.2' into myproject

    

    Change-Id: I31e82cd6a40c775760e1c7e544ec423854aaf2be

But when I try to push this merge commit to refs/for/.. branch it fails with

Counting objects: 3, done.

Delta compression using up to 40 threads.

Compressing objects: 100% (3/3), done.

Writing objects: 100% (3/3), 428 bytes | 0 bytes/s, done.

Total 3 (delta 2), reused 0 (delta 0)

remote: Resolving deltas: 100% (2/2)

remote: Processing changes: refs: 1, done    

remote: (W) 6931e48: commit subject >65 characters; use shorter first paragraph

remote: ERROR: missing Change-Id in commit message footer

remote: 

remote: Hint: To automatically insert Change-Id, install the hook:

remote: curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://gerrit-review.googlesource.com/tools/hooks/commit-msg ; chmod +x `git rev-parse --git-dir`/hooks/commit-msg

remote: And then amend the commit:

remote:   git commit --amend

remote: 

To https://chromium.googlesource.com/chromiumos/third_party/kernel

 ! [remote rejected] HEAD -> refs/for/chromeos-3.8 (missing Change-Id in commit message footer)

error: failed to push some refs to 'https://chromium.googlesource.com/chromiumos/third_party/kernel'

As my merge commit has correct 'Change-Id' footer I believe remote server still validates upstream changes.

I wonder if Gerrit does not count 'sandbox' branch as a real branch with merged changes.