How can I fork a repository on Gerrit, so that the forked repository retains the change list history of the forked-from project?
I don't mean to fork from one Gerrit instance to another. Just within one Gerrit instance, rather than creating a new repository and submitting all contents of the other project in one big CL, actually forking/cloning that repository to retain a common CL history
Gerrit doesn't have the "concept" of "fork". As you have said, you can create a new repository and push all the commits/tags of the original one to it, or you can simply create a new branch in the original repository.
Related
This issue has been puzzling me for quite sometime now, please help.
Two teams have been working on a project developing 2 submodules:
Team 1: Develops submodule 1 and does a commit and raises a gerrit, say, 233421 (which is UNMERGED, in code review)
Team 2: Does cherrypick of submodule 1 with id 233421, and does a commit of submodule 2 and pushes (gerrit id say 233422)
In step2 above, along with creating a new patchset (233422) for submodule 2, it also updates the cherrypicked patchset 233421.
How to force stop to not update cherrypicked patchset and only create a SINGLE new gerrit with submodule 2's changes in it?
First of all, you should not cherry-pick an unmerged change and use it as a base for a new change. If you really want to do that, you can change the Chante-Id of the new commit created after the cherry-pick, so Gerrit will create a new change for it, instead of updating the original one. I don't think this process is the best but it'll solve the issue you're talking about.
I have a problem with getting Google's Repo, gerrit & Jenkins working together.
our setup:
we have a Repo build out of few git repositories, which are all on our gerrit server. Manifest is also there.
Workflow:
user do changes in few files which sits in different git repositories in the Rep.
user commit & push the changes to Code review.
Problem:
for each of the repositories, a separate gerrit code review is created.
For each of those code reviews, Jenkins is being triggered.
If the changes are inter-depended (which they usually do), the Jenkins build will fail, as it takes only the changes in one repository each time.
How do we make Jenkins/Gerrit co-op to get the full changes into one build (that will work)?
Thanks
The configuration described here is very problematic,
and is sure to cause you grief in the future as well.
In the long run, consider one of those paths:
Reduce dependency between the components to the minimum
(this is preferred)
Merge the code to a single repository
Meanwhile -
Make sure the verification-job (in Jenkins) checks-out the latest code from all the other repositories
(those that are relevant for building this change)
Make (non-breaking) changes to one repository at a time
(requires some planning, of course)
Within Bamboo I have several linked repositories. Each one of these repositories are connected to a specific branch, which you have to set through Bamboo's web interface. Is it possible to dynamically choose the branch without having to go in and change the linked repo branch every single time?
Yep, Bamboo supports branches, both manually added and automatically detected without new repository needing to be created. You just need to let it know where you keep branches in your repo.
https://confluence.atlassian.com/bamboo/using-plan-branches-289276872.html
Scroll down to managing plan branches in bamboo. They reference feature branching at the top of this article, but you don't have to be using that paradigm to get some use out of the branching support in bamboo.
I have two apps/projects - one for customers and one for workers. Both projects have the same back-end API related code, the same business-level objects, the same custom GUI controls and some functionality. I want to replace the identical code with the shared one. For example to move this code to a separate repo.
Since both projects are under development everything (including shared code) will be changed very often. Shared code will be usually updated as a part of one of these two projects.
What is the best way to share the code between two projects if I need an easy way to frequently update it?
My ideal use case will be the following:
I change the customer project (customer and shared code).
I commit and push new changes to the customer repo and to the shared code repo.
I open worker project, do pull for the shared code and then update worker code if it needs to reflect shared code changes.
P.S. Qestions Differences between git submodule and subtree and GIT Nested repositories: Composer vs. SubModules vs. Subtree vs.? have very good answers but it is still not clear what should I choose if I need an easy way to frequently update shared code.
I would use a git submodule personally, it's a very good link to a shared codebase that is itself a git repository that can be managed separately without being tracked in your other projects.
You can use git submodule foreach git pull origin master on both the client and worker side to pull in changes when the shared library is updated.
Is it possible to do pull request in bitbucket style in Phabricator?
Eg. to branch off of some existing branch and then to create pull (merge) request to merge new branch back?
I see that Phabricator differential tool only allows to submit some manually entered diff to some branch. Is it the only way?
You can mix git and arc together, but it does go against how arc diff is meant to be used.
You could leverage audit instead, although I haven't gone into any details about that below (nor have I used audit, yet).
Below, I've tried to explain our new workflow, coming from git-flow to an adapted version using git and arc diff.
Background
Before we started using Phabricator we used Gitlab and created merge requests. These would get reviewed by another developer. We use JIRA and our workflow incorporates a review required stage which has several checks before progressing into testing.
At this point, we've pushed the branch to the remote, requested a review and awaiting testing to occur (we have a mix of both manual and automated testing).
Once the review has been accepted and tests have passed, the feature branch is merged into origin/develop.
New workflow
Our new workflow removes the need to create the merge request within Gitlab, especially for reviewing.
My team still uses a workflow that incorporates git-flow, however, we've introduced the arc diff command. This creates the diff within Phabricator. The developer pushes his branch to the remote, but doesn't raise a merge request.
We run the following commands when creating a diff (merge into origin/develop)
git checkout -b feature/foo
git add <files>
git commit -m "A useful commit message"
git push origin feature/foo
arc diff origin/develop # this creates the diff within diffusion
Once the review has been accepted, we don't merge (or arc land) the branch, we await all testing to take place. This allows us to update the diff should testing fail and the developer who reviews can easily see which commits need reviewing.
Once testing has passed we can simply merge, either using gitlab merge request or the command line. We usually run arc close-revision <revision-id> to close the revision within Phabricator itself.
Additional notes
I believe the philosophy of arc diff is that you don't push your local branch. Instead you create a diff which diffusion displays. This is classed as a pre-push workflow.
Phabricator also has a post-push workflow which incorporates audit. You can simply mark commits ready for audit by amending your commit messages.
No, see https://secure.phabricator.com/T5000 to track this feature request.
Differential's primary input should be Arcanist, the Phabricator command line tool. It wraps git and provides lint, unit, and other precommit checks that help reduce time spent reviewing code. For example, it can emit patches and amend code before submission for review.
https://secure.phabricator.com/book/phabricator/article/arcanist/