I have launchpad repo which I'm pushing commits, and my friend wants to push a patch file into it but when he tried he got this error.
$ bzr push :parent
bzr: ERROR: Cannot lock LockDir(chroot-90567632:///~catchsudheera/maria/pcre_regex_enhance/.bzr/branch/lock): Transport operation not possible: readonly transport
How would I give him the required permissions? thank you very much.
PS : bzr info results:
sudheera#Dr-HOUSE-PC:~/Gsoc/mariadb/repo5/maria$ bzr info
Standalone tree (format: 2a)
Location:
branch root: .
Related branches:
push branch: bzr+ssh://bazaar.launchpad.net/~catchsudheera/maria/pcre_regex/
parent branch: bzr+ssh://bazaar.launchpad.net/+branch/maria/
Branches starting with address lp:~catchsudheera are your private branches on Launchpad. It is not common to let other users push to these branches.
Ask your friend to push to his own Launchpad account, for example lp:~hisusername/maria/pcre_regex_enhance. After that, he can visit the page of his branch on Launchpad, https://code.launchpad.net/~hisusername/maria/pcre_regex_enhance, and use the Propose for merging link to propose the branch for merging into yours. You can then merge his branch in your workspace and push it to your own branch.
Related
When using Gitlab or Github to manage code, after merged a merge request or pull request for dev to master, the HEAD of dev always fall behind HEAD of master one commit because of the default merge command is git merge with --no-ff.
How to make HEAD of dev to be the same as HEAD of master?
I find some command online:
git checkout dev
git merge master --ff-only
Is it right? Is it reasonable to merge master into dev?
You should never merge public branch into your own feature branch.
Try git rebase master
I just pushed some code to a new branch in my remote repo feature\add-user. In my local repo I am currently on an older branch, which feature\add-user builds on to. I am using TortoiseGit, but when attempting to checkout the new feature branch, feature\add-user does not show up and there is no option to type the name of a branch. The branch is visible in the remote repo itself.
I've tried pulling the latest version of the branch I'm currently on thinking this may "refresh" TortoiseGit's view of the remote repo, but to no avail. Aside from cloning a new copy of the remote repo at feature\add-user is there a way to find this new feature branch using TortoiseGit?
In the switch/checkout dialog your could selected the origin branch, and that will make a new local branch.
For example with the branch "dev" which is only at origin and not local:
if you can't select the origin branch, you could fetch it after pushing the "..."-button:
I'm trying to tag the git repo of a ruby gem in a Bamboo build. I thought doing something like this in ruby would do the job
`git tag v#{current_version}`
`git push --tags`
But the problem is that the repo does not have the origin. somehow Bamboo is getting rid of the origin
Any clue?
Yes, if you navigate to the job workspace, you will find that Bamboo does not do a straightforward git clone "under the hood", and the the remote is set to an internal file path.
Fortunately, Bamboo does store the original repository URL as ${bamboo.repository.git.repositoryUrl}, so all you need to do is set a remote pointing back at the original and push to there. This is what I've been using with both basic Git repositories and Stash, creating a tag based on the build number.
git tag -f -a ${bamboo.buildNumber} -m "${bamboo.planName} build number ${bamboo.buildNumber} passed automated acceptance testing." ${bamboo.planRepository.revision}
git remote add central ${bamboo.planRepository.repositoryUrl}
git push central ${bamboo.buildNumber}
git ls-remote --exit-code --tags central ${bamboo.buildNumber}
The final line is simply to cause the task to fail if the newly created tag cannot be read back.
EDIT: Do not be tempted to use the variable ${bamboo.repository.git.repositoryUrl}, as this will not necessarily point to the repo checked out in your job.
Also bear in mind that if you're checking out from multiple sources, ${bamboo.planRepository.repositoryUrl} points to the first repo in your "Source Code Checkout" task. The more specific URLs are referenced via:
${bamboo.planRepository.1.repositoryUrl}
${bamboo.planRepository.2.repositoryUrl}
...
and so on.
I know this is an old thread, however, I thought of adding this info.
From Bamboo version 6.7 onwards, it has the Git repository tagging feature Repository Tag.
You can add a repository tagging task to the job and the Bamboo variable as tag name.
You must have Bamboo-Bitbucket integrated via the application link.
It seems that after a checkout by the bamboo agent, the remote repository url for origin is set as file://nothing
[remote "origin"]
url = file://nothing
fetch = +refs/heads/*:refs/remotes/origin/*
That's why we can either update the url using git remote set-url or in my case I just created a new alias so it does not break the existing behavior. There must be a good reason why it is set this way.
[remote "build-origin"]
url = <remote url>
fetch = +refs/heads/*:refs/remotes/build-origin/*
I also noticed that using ${bamboo.planRepository.<position>.repositoryUrl} did not work for me since it was defined in my plan as https. Switching to ssh worked.
When I sync from the ToolTwist Designer, I select the files I wish to publish, but I get an error when I press OK, saying that the sync failed and to look in the server log file.
If I try again, the files I selected are no longer in the list, but if I check Git I can see they are not pushed to the repository.
In the log file I see that the push failed, and if I go to the webdesign directory and test the push command I get the same error:
$ git push --dry-run
To git#github.com:MyRepository/design-project.git
! [rejected] master -> master (non-fast-forward)
I'm using the 'design' branch, so I'm not sure why an error is occurring on the 'master' branch.
In normal circumstances the Designer only uses a single git branch, normally named 'design'. The error message above indicates a conflict on the master branch.
It appears that changes have been committed to the master branch on the local machine but not pushed, whilst elsewhere changes have been committed to the master branch and have been pushed onto the remote repo.
To clear this conflict you'll need to checkout the master branch and do a pull to merge in the changes on the remote, and then the next push will work. Don't forget to change back to the design branch when you're finished.
[stop the Designer]
$ git checkout master
$ git pull
[resolve any conflicts]
$ git push origin master
$ git checkout design
[start the Designer]
By default git tries to push commits on all branches. In this case, you might find that the conflict on the master branch is preventing your web design changes on the design branch from being committed. To prevent this from happening, you can configure git's default behaviour to only push the current branch.
$ git config push.default current
You might also want to investigate why the master branch is being changed (and in two locations).
In my project , i have local branch for working and branch on network drive
i did "bind branch" between local one and network one
My idea is to use the bind option for auto backup of each local commit.
After i commit files in the local branch , i receive a message in network branch
" Working tree is out of date, please run 'bzr update'."
my question is :
Log on network branch will show the updated tree . Does the files are updated ? or i must do "update" ?
automirror plugin will help me for this scenario?
thanks
Binding a local branch to a remote branch means that commits to the local branch will automatically push that commit to the remote branch. If the remote branch and the local branch are not in sync, the commit will fail and neither the local or remote branch will be affected and your changes will still be sitting in your working tree. To get your local branch in sync with the remote branch, use bzr update.
If your network branch has a working tree, then the working tree is not automatically updated when commits are pushed from the local branch into the network branch. The network branch's working tree has to be updated with bzr update or plugins like automirror or push-and-update.
Unless you actually need the working tree in the network branch, I would recommend that you reconfigure the branch to be tree-less using bzr reconfigure --branch. If you have a shared repository that the network branch belongs to, you will also need to use bzr reconfigure --with-no-trees on the repository to stop it creating trees on new branches.
The 'bind branch' feature will succeed only if your local and network branches are up-to-date.
So the commit failed as there is a difference between these 2 working copies.