How clone a specific branch in bitbucket - ruby-on-rails-3

I have a remote repository hosted in bitbucket, but when I want clone this repository to my pc
Bitbucket clones the master branch
I want clone another branch called static_pages_exercises hosted too in the same remote project. Is that possible.
Error:it clones the remote master branch no the remote static-pages-exercises branch
daniel:~/workspace$ mkdir sample_app
daniel:~/workspace$ git init .
Reinitialized existing Git repository in /home/fernando/workspace/.git/
fernando#fernando:~/workspace$ git clone git#bitbucket.org:ferbad1212/sample_app.git
Cloning into 'sample_app'...
remote: Counting objects: 139, done.
remote: Compressing objects: 100% (124/124), done.
remote: Total 139 (delta 42), reused 0 (delta 0)
Receiving objects: 100% (139/139), 23.05 KiB, done.
Resolving deltas: 100% (42/42), done

Try the below command
git clone --branch branchname cloneUrl
example
git clone --branch feature https://cloneurl

Related

Yocto submodule update failure

I have a server with two git repos on (affinage.git and avondalelibs.git) They contain code built using cmake and make.
I have access on my machine to the server using ssh - the keys are good.
The repo 'affinage' uses 'avondalelibs' as a submodule.
When I clone affinage natively (i.e. not using yocto) the following happens:
chrisbrown#thebeast:/tmp$ git clone ssh://server#thebeast:/home/server/serverrepo/affinage.git
Cloning into 'affinage'...
remote: Enumerating objects: 307, done.
remote: Counting objects: 100% (307/307), done.
remote: Compressing objects: 100% (296/296), done.
remote: Total 307 (delta 158), reused 0 (delta 0)
Receiving objects: 100% (307/307), 2.10 MiB | 7.04 MiB/s, done.
Resolving deltas: 100% (158/158), done.
chrisbrown#thebeast:/tmp$ cd affinage/
chrisbrown#thebeast:/tmp/affinage$ git submodule update --init --recursive
Submodule 'avondalelibs' (ssh://server#thebeast/home/server/serverrepo/avondalelibs.git) registered for path 'avondalelibs'
Cloning into '/tmp/affinage/avondalelibs'...
Submodule path 'avondalelibs': checked out '52d2adc212700056c4b3c9c672702da33073f86a'
Which is good.
When I use Yocto (dunfell) to build the same repo it fails:
Log data follows:
| DEBUG: Executing shell function do_configure
| Submodule 'avondalelibs' (ssh://server#thebeast/home/server/serverrepo/avondalelibs.git) registered for path 'avondalelibs'
| Cloning into '/home/chrisbrown/affinage/poky/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/affinage/1.0-r0/git/avondalelibs'...
| Permission denied, please try again.
| Permission denied, please try again.
| server#thebeast: Permission denied (publickey,password).
| fatal: Could not read from remote repository.
Yocto succeeds in cloning the top repo but fails in initialising the submodules. I am initialising them with a do_configure_prepend() as below:
do_configure_prepend() {
cd ${WORKDIR}/git
git submodule update --init --recursive
}
I can't understand why if both repos are from the same server with the same keys there is a 'permission denied'. Anyone know why this might happen?

How to solve merge conflict in a approved review in gerrit?

I made a change in gerrit which was code reviewed and after 7 revisions approved. But, now it cannot be merged and trying to rebase in gerrit website is not working due to merge conflict. How can I resolve this merge conflict and merge the same approved change and not create a new one.
(Full steps from cloning the repo would be appreciated.)
1) Clone the Gerrit repository
git clone https://USER#GERRIT-SERVER/a/REPO-FULL-PATHNAME
2) Go to the change page on Gerrit and copy the checkout patch command
git fetch https://USER#GERRIT-SERVER/a/REPO-FULL-PATHNAME refs/changes/XX/YYYYY/Z && git checkout FETCH_HEAD
3) Rebase the change
git rebase origin/BRANCH
4) Solve the conflicts
git mergetool
5) Continue the rebase
git rebase --continue
Repeat the steps 4 and 5 until the end of conflicts
git commit --amend
Note: Keep the same Change-Id
6) Send the new patchset to Gerrit
git push origin HEAD:refs/for/BRANCH
The accepted solution works but I personally disagree with this workflow. It is unnecessarily cumbersome.
I prefer a workflow with exactly one merge and therefore less steps.
Clone the Gerrit repository if not already available
git clone https://[USER]#[GERRIT-SERVER]/a/[REPO-FULL-PATHNAME]
Checkout the Gerrit patch
git fetch https://[USER]#[GERRIT-SERVER]/a/[REPO-FULL-PATHNAME] refs/changes/46/12346/N && git checkout FETCH_HEAD
Soft-reset the change and stash it
git reset --soft HEAD~1 && git stash
Checkout branch or the Gerrit patch you want to rebase onto
git checkout origin/BRANCH
# or fetch other Gerrit patch:
# git fetch https://[USER]#[GERRIT-SERVER]/a/[REPO-FULL-PATHNAME] refs/changes/45/12345/N && git checkout FETCH_HEAD
Unstash the previously stashed changes
git stash pop
Solve the conflicts with your favourite 3-way merge tool.
Commit the merged changes - NOT (!!) amend them - and use the same Change-Id from the merged patch in the message:
git commit -am "[COMMIT-MESSAGE]\
\
Change-Id: [FORMER-CHANGE-ID]"
Send the new patchset to Gerrit
git push origin HEAD:refs/for/BRANCH
Done. One merge!
I additionally use the gitreview tool. That makes it extra easy. Steps 2, 3, 4 and 5 then can be chained.
git review -d 12346 && git reset --soft HEAD~1 && git stash && git review -d 12345 && git stash pop

submodule project not present in `git submodule status` roster and unable to commit from parent as single object

I use git submodule add <GitHubURL.git> to add projects as submodules to a main "parent" project repository.
Parent_Project_repo
- SubA_repo
- SubB_repo
- SubC_repo
- Sub_Problem_Child_repo
As I work in the submodules, I make commits within the Sub*_repo project (per usual, committing whichever files I have worked on). In the parent project, however, usually I am just making a single commit for all the submodules commits. This single commit of the submodule usually shows up like so in the Parent_Project_repo:
I have recently added a submodule which, from the parent repository, displays each individual file in the commit history instead of just accessing all the files/commits in one single "Subproject" commit object.
Of note:
this problematic submodule does not show up in the roster when I
invoke:
git submodule status
It is listed in the
Parent_Project_repo/.gitmodules
Parent_Project_repo/.git/config
file as a submodule & there is a corresponding
Parent_Project_repo/.git/modules/Sub_Problem_Child_repo/ folder.
How can I get the problem child into the roster and able to have all it's commits handled by the Parent_Project_repo as one object?
UPDATE:
The only difference I have discerned with the “problem child” submodule is that it doesn’t have a “historySha” key in the /.git/modules/config file, e.g.:
[atomGithub]
historySha = 1936e4c373c130860a8f92683b517dad713ec37
Also, these commands don't get the Problem child listed in the status:
$ git submodule update --init --recursive
$ git submodule update --recursive
$ git submodule init
...nor showing up on GitHub in the Parent project with a "# e78c392" which indicates I can double click the link and got to that repo instead of a copy inside the superproject (Parent).
If git submodule add <URL> was used to set up a git repository as a submodule within a "super-project" and the submodule is NOT committing within the super-project as a single object (i.e. if, when committing the submodule from within the Super project you are having to commit each individual file from the submodule), then follow these steps to reconfigure:
Save all work in the submodule.
Stage and commit all file changes.
Push all commits to GitHub.
Make a safety copy of the submodule folder if you are cautious
Delete the relevant submodule section from the super-projects .gitmodules file (i.e. remove the listing of the problem submodule).
Stage the .gitmodules changes git add .gitmodules
Delete the relevant sunmodule section from super-projects .git/config.
Run git rm --cached -rf PATH_TO_SUBMODULE where PATH_TO_SUBMODULE is the actual path to the submodule folder.
Run rm -rf .git/modules/PATH_TO_SUBMODULE.
Commit git commit -m "Removed submodule commit message".
Delete the now untracked submodule files: rm -rf PATH_TO_SUBMODULE
git submodule add <URL>
Test to see if a change (fwiw, modify two files) in the submodule is handled as a single object when committing in the super-project.
Success? Delete the safety copy of the submodule project.

Trying to install MariaDB on Dokku

I'm on my Server via ssh and trying to install MariaDB plugin for Dokku:
root#CHF:/var/lib/dokku/plugins# sudo git clone https://github.com/krisrang/dokku-mariadb mariadb
Cloning into 'mariadb'...
remote: Counting objects: 68, done.
remote: Total 68 (delta 0), reused 0 (delta 0), pack-reused 68
Unpacking objects: 100% (68/68), done.
Checking connectivity... done.
root#CHF:/var/lib/dokku/plugins# sudo dokku plugins-install
2016/03/24 15:10:42 open /var/lib/dokku/plugins/available/mariadb/plugin.toml: no such file or directory
2016/03/24 15:10:42 open /var/lib/dokku/plugins/available/md-plugin/plugin.toml: no such file or directory
root#CHF:/var/lib/dokku/plugins#
What am I doing wrong here?
Its not installed, I can't create a database and tables..
I tried also this way:
sudo dokku plugin:install https://github.com/Kloadut/dokku-md-plugin
--name mariadb
Check the output of ls -lha /var/lib/dokku/plugins/enabled
There are two directories inside /var/lib/dokku/plugins/ : available and enabled.
"available" contains every plugin that was installed and not yet uninstalled;
"enabled" contains all plugins that are being used. Each plugin that is being used is actually just a "shortcut" pointing to a another directory.
Taken from here
If you see a plugin you deleted outside of dokku, remove it with rm -r /var/lib/dokku/plugins/available/pluginNameHere
Those two plugins are not compatible with the latest version of dokku.

Can I take a bazaar branch and make it my main shared repository?

I have a bazaar repository on a shared server. I'd like to clean up the repo and set it up from scratch but maintain my history. I don't know how the repository was created initially (is there a way to find out?).
Can I take a branch and make that into my main shared repo?
Is this a viable process:
bzr init-repo --no-trees /home/bzr/myrepository
cd /home/bzr/myrepository
bzr init stable
cp /home/oldbzr/branch_taken_from_current_repo/* ./stable/
cp /home/oldbzr/branch_taken_from_current_repo/.bzr ./stable/
Thanks
A "branch" and a "repo" in Bazaar are totally separate concepts. You don't convert a branch into a repo. What you usually think of as a repo (in SVN or Git, for example) is actually a branch in Bazaar. What you want to do is create a new repo, then copy the old branch into the new repo.
You almost have it right, but you don't want to use "cp", you want to use "bzr branch". Note: You can usually use "cp" to copy branches except when you want Bazaar to move a branch into, out of, or across a repository -- then you need "bzr branch" to intelligently repack the history. So here is what you want to do:
bzr init-repo --no-trees /home/bzr/myrepository
cd /home/bzr/myrepository
bzr branch /home/oldbzr/branch_taken_from_current_repo stable
Note that I am not doing "bzr init" -- I don't want to create a new branch, just copy the old one. And I am not manually copying the old branch or its .bzr directory. If you copy the old branch's .bzr, it will not end up using the new repository. By doing a "bzr branch" it will go "oh hey, I am moving into a repository. Therefore, I will put all of my commit data into the shared repository, and just put a lightweight branch in 'stable'."
You can use just plain branch into your shared repo as mgiuca suggested, but you also can convert your standalone branch to use shared repository. For that your steps should be extended with bzr reconfigure call:
bzr init-repo --no-trees /home/bzr/myrepository
cd /home/bzr/myrepository
bzr init stable
cp /home/oldbzr/branch_taken_from_current_repo/* ./stable/
cp /home/oldbzr/branch_taken_from_current_repo/.bzr ./stable/
cd stable
bzr reconfigure --use-shared
So, if we omit cp then you can create a shared repository "around" your branch:
cd /path/to/my/branch
bzr info # you should see you branch is standalone,
# i.e. not using shared repo
bzr init-repo ../ # create shared repo in parent directory
bzr reconfigure --use-shared # convert standalone branch to repository branch
bzr info # now you should see your branch is using shared repo