I've already created a remote branch and pushed to it some commits. How can I create a gerrit review on commits already existing on the remote branch?
One workaround is to add an empty space in the commit message, thus changing the SHA-1 and then performing git review. I was wondering if there's a possible solution (perhaps directly in the gerrit web ui?) without modifying the commits.
Some possibilities:
Merge this already existing branch in another branch creating a change (review) for this (pushing the merge commit to /refs/for/BRANCH).
Revert these commits and after that push them to review again.
Related
In my company we have the following workflow: development is done on a dev branch, once author wants to merge the changes he/she squashes the changes and create a Pull Request. If during the review turns out the rework is needed then the author adds new commits to the branch. Once everything is approved the author should squash commits and rebase the code (if needed). Then the maintainer merges the branch to the master branch, which results in one commit only to be added (plus the merge commit). This is to keep the log neat.
However occasionally the maintainer overlooks the fact the commits on the dev branch weren't squashed which results in multiple "work in progress" commits to be included in the master branch. We want to avoid the situation. The question is how to do that?
I was looking through Pull Request "merge check" plugins that could e.g. disable "Merge" button if there is more than 1 commit between source and destination branches, but so far I haven't found any.
I know we could enable automatic squashing on merge but we decided not to squash automatically. We feel it's better for us if the squash is done manually by the developer, e.g. commit message may be corrected accordingly.
Correcting the history in the master branch is also not possible due to our policy forbidding rewriting history on that branch.
I have a Bitbucket repo where the most recent changes are pushed by another developer teammate. His push is more important and I want to make sure my local is same as the latest in the repo. I have not made any changes but still Xcode shows me this warning. I am fine is all my local is overwritten. How do I do it? Should I check the box when I am pulling changes in Xcode from the BitBucket repo? Or do I need to do a git pull from terminal?
If you want to merge another branch into yours, you should always commit your changes first. When conflicts emerge, you just solve them and there you go, you are on the latest commit with your changes preserved.
If, however, you prefer rebase instead of merge - you HAVE to commit your uncommited changes first, then you can rebase on the latest commit from the other developer's branch, the nice thing about rebase is that it keeps the git history cleaner while also leading you trough the conflict solving, because it basically tries to put each commit of yours on top of the commit that you are rebasing onto, so it sort of "guides" you trough resolving conflicts as you have small chunks of code to resolve and then continue rebase.
Try to read more on this. This article summarises the difference between merge and rebase:
https://www.freecodecamp.org/news/an-introduction-to-git-merge-and-rebase-what-they-are-and-how-to-use-them-131b863785f/
I want to create a TFS policy that blocks a changeset from being checked in if a certain keyword is found in the diff.
This will allow me to make local changes for testing ideas without worrying that these changes will be mistakanly checked in, as long as I add something like //nocommit in the code.
How can this be done?
There is no out-of-box check-in policy to achieve your requirement, you have to customize your own check-in policy and use command tf diff itemspec /noprompt to compare files.
As a suggestion, you could consider using Git version control, create a branch from master and work on the branch. When you are ready to merge your code to master, create a pull request to review the code. In order to protect master, you could set branch policy on master. After you set up a branch policy, you cannot directly push changes to the branch. Changes to the branch are only made through pull requests.
We're using Gerrit. We thought we could do the following:
create some commits on a topic branch:
- a
- b
- c
Push those commits to gerrit.
Get some reviews.
Have Jenkins build only the last commit of the bunch.
Unfortunately, it looks like gerrit internally creates three different branches for those three commits, and when we have Jenkins run the script to build the topic, it winds up picking a different commit than the one we intended. Is there someway to get the behavior we desire?
You can change the project configuration to only create one review for your series of changes. This can be done by setting the Create a new change for every commit not in the target branch to false
Biggest disadvantage is that you can't review what has been changed in the changesets leading up to the latest change.
See the Gerrit Documentation
Gerrit always creates one change (review) for each commit pushed. There's no way to create one unique change for a bunch of commits. Commits are stored in special branches (like, for example, refs/changes/12/40312/1) until they aren't submitted (merged in the final branch).
You can, of course, build several commits at once after they are submitted to the branch but you only can trigger Jenkins to start a build every time some commit is merged in the branch (one build for each commit). If you want to have just one build for a bunch of commits you could consider to make scheduled builds started automatically some time of the day (night builds).
When using Gerrit Code Review - is it possible to checkout all unreviewed changes for the master branch in one go? I know it is possible to checkout a specific patch set (https://gerrit-documentation.storage.googleapis.com/Documentation/2.12.2/intro-quick.html#_trying_out_the_change), but I would like to get all pending-review commits for the master branch.
Background: we currently aren't using Gerrit yet but we are going to. We have both automated and manual testing of the master branch and I would like to be able to keep on using that, before the review step, so I need to be able to checkout a branch with all pending-review commits.
AFAIK, Gerrit does not provide that feature. In fact, I am not sure if that is even possible without human interaction. If there are N independent unreviewed commits to master, there could be conflicts between them that would make it impossible to automatically build up a branch made of all N commits on top of master.