What's the correct process for adding a dozen or more commits from master to a release branch? Do they have to be done as individual patches? Or is it common to squash them? Or something else? Or should one just not let release branches get that far behind? :)
About this board
For archived talk, see Talk:Git/Workflow/archive
Cherry-picking multiple commits?
Release branches here don't normally have that much backported to them, mainly just security fixes and fixes for major bugs. When they do get backports, it's done by cherry-picking the individual patches.
I suppose it's possible some extension or the like follows a different model.
Ok, cool, good to know I'm not missing anything obvious. :)
And yeah, it's mostly for extensions that I'm thinking — where they're following a release branch policy, it seems like it's a good idea to ensure all commits are backported unless they're not compatible, because we recommend people checkout e.g. REL1_31 but they mightn't actually get any updates on that branch ever, and so are left further behind than they could be.
The benefit of cherry-picking is mostly that it integrates well with Gerrit. Specifically that 1) Clicking on or searching for the Change-Id reveals the change in all branches, 2) Using the "Included in" interface correctly shows the branches the change is a part of.
I'd expect cherry-picks for MediaWiki core. But individual extensions may do it differently if maintainers agree.
So the workflow could just be to merge a bunch of commits from master to REL1_31 locally, and then push all at once? But that requires particular permissions on Gerrit doesn't it? Normally, it'd just result in a separate patch being created for each commit, I think. I'm not sure how CI would work in that scenario anyway, because it'd still want to be testing each commit...
Sounds like the single-commit cherry-pick way is best, if a bit slower.
[remote rejected] ("branch not found")
Doing a "git push-for-review" (we are working on windows meaning that this phyton script thing is a no/go, so instead using we are using the manual setup setting the alias before push to "git config alias.push-for-review "push origin HEAD:refs/for/bug37446") results in nothing more than:
remote: Resolving deltas: 100% (4/4) To ssh://email@example.com:29418/mediawiki/extensions/SemanticResultF ormats.git ! [remote rejected] HEAD -> refs/for/bug37446 (branch bug37446 not found) error: failed to push some refs to 'ssh://firstname.lastname@example.org:29418/med iawiki/extensions/SemanticResultFormats.git'
We create a branch bug37446, did the rebase, and checked that the SSH key is working (we are able to execute "ssh -p 29418 email@example.com").
The questions that are left what does this error mean and how do we resolve this? (Personally I use github for quite a while and I hadn't had any issues with git but this gerrit setup is somehow confusing.)
There is no such remote branch for you to push to--see https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/SemanticResultFormats,branches
Yes, I know that but than since I want to commit certain changes only to a branch, how do I create a branch? You can't expect people to commit patches (because the rational behind git was that "branching gets much easier") when you don't explain how to do create a branch.
With Gerrit this is a bit different story. Gerrit acts as a gatekeeper and only accepts commits into pre-defined git branches because it needs to know where an approved commit should be merged after a successful review. So forget about "branching gets much easier" part as far as Gerrit is concerned.
Gerrit project administrator can create Gerrit branches in the repository.
Please see the mailing list for more details: "Gerrit question: pushing to another branch".
I hava no idea about that
Cross Project Dependencies has a broken link
The link http://docs.openstack.org/infra/zuul/gating.html#cross-repository-dependencies No longer exists. I can't find anything there that might be appropriate (didn't have much time to search).
Thanks for reporting this. Fixed in https://www.mediawiki.org/w/index.php?title=Gerrit%2FAdvanced_usage&type=revision&diff=2540616&oldid=2477577
How to fix [OUTDATED] dependency on a patch
I am working on a patch that depends on another that's still under review.
- Patch A: parent patch still under review.
- Patch B: depends on A.
I have made new patchsets for A and on patch B's page, Gerrit shows that the dependency(patch A) is [OUTDATED].
Steps I have followed to fix this issue:
- Checked out patch A (git review -d 'patchA')
- Checked out existing patch B (git review -d 'patchB')
- git rebase review/user/patchA
- makes changes to a file
- git add 'files'
- git rebase --continue shows 'No rebase in progress?'
- git commit --amend
- git push gerrit HEAD:refs/for/master
git push throws error ' ! [remote rejected] HEAD -> refs/for/master (squash commits first)'.
How can I fix this?
In fact, what about getting rid of this page?
After seeing Git/Getting started, Git/Tutorial and Git/Code review/guide I see no point in keeping this page. Proposal: keep removing sections making sure that any useful content goes to the appropriate pages and then leave a redirect to Git/Getting started.
Remember that experienced users sometimes need a reference too, e.g. to look up the exact syntax for
git push gerrit HEAD:refs/for/master. Having to dig through multiple random beginner-oriented pages to find this information would not be productive.
Merging How we review with
Removing Git installation instructions from Workflow
In order to fix Bug 36437 - A strict and correct Git workflow document is needed one thing we can do is to remove from the Workflow document anything that is not strictly part of the workflow. I already removed the Justification section, and the Git installation instructions could follow. It is a one time action with no MediaWiki-specific steps and there are plenty of sites out there documenting very well how to do this.
Gerrit for MediaWiki core and extensions or anything?
Our docs mention frequently that Gerrit code review is for MediaWiki core and extensions, but nowadays is more than that, isn't it? It would be better to say that we use Gerrit code review for anything. If there are exceptions (projects using GitHub only) then we can specify them somewhere.
Also, since we have everything mirrored in GitHub it would be nice to tell (especially to newcomers) what to do with that, and whether patches can be submitted that way.
Permission denied (publickey)
kozuch@kozuch-VirtualBox:~$ git clone ssh://Kozuch@gerrit.wikimedia.org:29418/mediawiki/core.git Cloning into core... Permission denied (publickey). fatal: The remote end hung up unexpectedly kozuch@kozuch-VirtualBox:~$ ssh -vT firstname.lastname@example.org OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 Sep 2011 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to gerrit.wikimedia.org [188.8.131.52] port 22. debug1: Connection established. debug1: identity file /home/kozuch/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/kozuch/.ssh/id_rsa-cert type -1 debug1: identity file /home/kozuch/.ssh/id_dsa type -1 debug1: identity file /home/kozuch/.ssh/id_dsa-cert type -1 debug1: identity file /home/kozuch/.ssh/id_ecdsa type -1 debug1: identity file /home/kozuch/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1 debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: RSA b5:e9:dc:b2:dd:6e:70:f7:18:8a:dc:a3:5d:ab:99:4d debug1: Host 'gerrit.wikimedia.org' is known and matches the RSA host key. debug1: Found key in /home/kozuch/.ssh/known_hosts:3 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/kozuch/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: Trying private key: /home/kozuch/.ssh/id_dsa debug1: Trying private key: /home/kozuch/.ssh/id_ecdsa debug1: No more authentication methods to try. Permission denied (publickey).
ssh-all -l is ok. PUB key copied to gerrit. Will someone help?
resolved by deleting the passphrase :-(
For your information, having passphrase on your key is not the problem. Many people have one (I'd even recommend it) and it works fine.
On Windows? Looks like people are having a lot of trouble on Windows.
I was breaking my head why this I couldn't login
untill I figuerd out that garret keys are diffrent from the wikitech keys
so you shouldn't add the keys in your wikitech settings
but instead you should use -
git review broken when cloning using review
When I cloned using the review shortcut recommended here:
git clone -o gerrit ssh://review/mediawiki/extensions/Onboarding.git
the .git/config looked like:
[remote "gerrit"] fetch = +refs/heads/*:refs/remotes/gerrit/* url = ssh://review/mediawiki/extensions/Onboarding.git
which makes sense. However, git review failed with:
Problems encountered installing commit-msg hook The following command failed with exit code 1 "scp -P 22 review:hooks/commit-msg .git/hooks/commit-msg" ----------------------- Permission denied (publickey). -----------------------
until I changed it to:
ssh review prints the standard "Welcome to Gerrit Code Review...Unfortunately, interactive shells are disabled." so I think the .ssh/config is correct. It's:
Host review Hostname gerrit.wikimedia.org Port 29418 User mattflaschen
Am I missing something, or are these instructions wrong? Does anyone know the specific cause?
As you can see when I spelled it out, I switched the repo. I'm in the process of retesting properly.
Saper confirmed this issue. I was still able to do the setup with the correct spelled out repo, so it's not a repo-specific issue.
It's git-review bug 912125. It does not understand SSH shortcuts and insists on "email@example.com:port" syntax.
Personally I prefer having an SSH shortcut and use
git fetch gerrit refs/changes/BB/AAAABB/PP
to fetch a patchset (git-review -d)
git push gerrit HEAD:refs/for/master
git push gerrit HEAD:refs/changes/AAAABB
to push changes to gerrit (equivalent of git-review without parameters).
You can ofc have two remotes: I sometimes use "review" with SSH shortcut for the above commands and "gerrit" for git-review. YMMV.