I try to use gerrit to do some test.
Use "git push origin HEAD:refs/for/master",
before gerrit code review, I want to do some test by Jenkins.
How to use command to clone the commit from "refs/for/master"?
or fetch to Jenkins job workspace in order to test?
There is only one branch.
"git branch" -> *master
When someone push a commit to review on Gerrit, the commit stays on the "magical" refs/for branch until it's finally submitted (merged). To have the commit locally you need to execute one of the download commands:
Checkout:
git fetch "https://GERRIT-SERVER/a/REPO-PATH" refs/changes/CHANGE-NUMBER && git checkout FETCH_HEAD
Cherry Pick:
git fetch "https://GERRIT-SERVER/a/REPO-PATH" refs/changes/CHANGE-NUMBER && git cherry-pick FETCH_HEAD
Format Patch:
git fetch "https://GERRIT-SERVER/a/REPO-PATH" refs/changes/CHANGE-NUMBER && git format-patch -1 --stdout FETCH_HEAD
Pull:
git pull "https://GERRIT-SERVER/a/REPO-PATH" refs/changes/CHANGE-NUMBER
On Gerrit 3.0, you you'll find these commands at the change screen, clicking on the 3 dots at the up-right and then in the "Download patch" option.
See more info at the Gerrit documentation here.
Using Jenkins, you can execute some of these commands too, but it's easier to use the Gerrit Trigger plugin.
Related
I want to do the pull request for my chapter_3.
However, it states that my main and chapter_3 are identical.
How to make my chapter_3 not identical with main? Below i also attached my git reflog
$ git add .
$ git commit -m "chapter 3"
$ git push origin chapter_3
Simply, in your local repository, add a new commit (or now commits) to chapter_3 and push.
Then, since chapter_3 has new commits that main has not, you will be able to initiate a pull request from chapter_3 to main.
The problem is: you were not on local branch chapter_3 when you did your commit. You were on main.
In order to avoid any mishaps, I would:
clone the repository again
create a chapter_3 branch
report your work for chapter 3 there (in the new local clone)
add commit and push
That is:
git clone https://github/com/<me>/<myRepo> newClone
cd newClone
git switch -c chapter_3
# work
git add .
git commit -m "Add chapter 3"
git push -u origin chapter_3
Then you can make your PR.
Notes:
replace <me> by your GitHub account name, and <myRepo> by your target repository name. Don't use < and >: they are placeholder makers.
replace newClone by a new local folder name which does not yet exist (it will be created by the git clone command).
On the install step, Travis CI clones the repo, which looks similar to this:
git clone --depth=50 --branch=master https://github.com/user/repo.git user/repo
How can I customize / override this?
Background: I am using tag based deploys. The way Travis checks out tagged builds (--branch=<tagname>), the git repository is in a detached state without access to branches. However, for deployment I need to know on which branch I am. My solution is to do a "normal" clone and then switch to the tagged commit.
You can clone the repository again in the install step. That way you clone the repository twice, but it seems to work.
# .travis.yml
install:
- git clone https://github.com/$TRAVIS_REPO_SLUG.git $TRAVIS_REPO_SLUG
- cd $TRAVIS_REPO_SLUG
- git checkout -qf $TRAVIS_COMMIT
Per the Travis docs you can add the following to your .travis.yml to remove the --depth flag:
git:
depth: false
As --depth implies --single-branch, removing this flag means that all branches will be checked out, which isn't the default behaviour.
I found that in order to get access to your whole repo you need the following:
install:
- git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
- git fetch --unshallow --tags
This way you'll have access to remote branches and tags (e.g. can do checkout).
If you're on a tag but no longer want to be in a detached HEAD state you can create a new branch that points to the tag (according to this discussion):
install:
- git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
- git fetch --unshallow --tags
- git symbolic-ref --short HEAD || git checkout -b ${TRAVIS_BRANCH}-test $TRAVIS_BRANCH
Note: git symbolic-ref --short HEAD will fail if you're in a detached HEAD state.
The problem is not really that you are in a detached branch. It is that git does not allow you to fetch the tags: git fetch --tags will only fetch the branch spcified by --branch in the git clone command you gave.
I explain this in more details this answer.
To solve you issue (checking out a specific tag) you can call a script that looks like this, after the repo is cloned:
# Keep track of where Travis put us.
# We are on a detached head, and we need to be able to go back to it.
build_head=$(git rev-parse HEAD)
# fetch the tags
git config --replace-all remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
git fetch --tags
# checkout the tagged commit
git checkout -qf <your tag>
# now do your stuff
# go back to where we were at the beginning
git checkout ${build_head}
Run this during your build to have access to origin tags / branches
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*" 1>/dev/null
git fetch origin -q
After that you can run this command to find branches containing your commit
BRANCHES=`git branch -a --contains "$TRAVIS_TAG"`
I've created a script a loooong time ago to fetch the 'environment' branch where the tag was created for continuous deployment purpose.
It may inspire you: https://gist.github.com/rolebi/a0eb1f783b7f3a5f21a631c8da1582dc
Use it like that:
TARGET_ENV="`test $TRAVIS_TAG && bash scripts/get_branch_for_git_reference.sh $TRAVIS_TAG`"
Disable git clone and then clone the repository again in the install step. The repository will be cloned only once in this way. In this "normal" clone you will able to do what ever you want.
git:
clone: false
install:
- git clone https://github.com/$TRAVIS_REPO_SLUG.git $TRAVIS_REPO_SLUG
- cd $TRAVIS_REPO_SLUG
Or you could just query the remote. Add the following to .travis.yml:
env:
global:
# get all the branches referencing this commit
- REAL_BRANCH=$(git ls-remote origin | sed -n "\|$TRAVIS_COMMIT\s\+refs/heads/|{s///p}")
# or check if we are on a particular branch:
- IS_RELEASE=$(git ls-remote origin | grep "$TRAVIS_COMMIT\s\+refs/heads/release$"
(I am surprised that the git gurus hadn’t come up with this one already)
You can convert the already existing shallow clone to a full clone. To do so execute git fetch --unshallow (available since git version 1.8.3) during the install step.
# .travis.yml
install:
- git fetch --unshallow --tags
The --tags flag forces to fetch all tags even if they don't belong to the checked out branch. This is needed if your build also depends on tags from other branches.
So I am very new to Github. Please forgive me if i am asking a stupid question. So first did some reading on Github and tried to understand the philosophy about it. So i am working on my first ruby on rails app (very excited) I generated my new app and made my first commit by pushing the empty app to Github. So now i have a master branch.
Then i created a couple of models and added some fields to the tables i made. Now i would like to push this change on Github . What do i do and how? I KNOW some of you will say why would you push a change so small but i am just trying to learn GIT so then when i work on huge projects i am ready.
I basically want to commit the changes to the masters . How do i do this? I USUALLY see other peoples gits and they have messages like "fixed feature 1" 1 hour ago etc. So i want to do the same.
Please advice.
You would do that just like you pushed your earlier code - by pushing the commits you have made to remote repository.
If you are on the master branch, this will do: git push origin master (replace origin with your remote name - git remote -v will tell you all your remote names).
If you are on a feature branch, you can checkout to the master branch and then merge your feature branch - git checkout master and then git merge <feature branch>, and then push your changes again using git push origin master.
EDIT:
You can add a shortname using git remote add origin <link to remote repository>, and then use origin to push.
I am new to git as well and the answer above sounds better then mine. I have bash script on github (https://github.com/caroldomokos/columbo) which is work in progress for some time. I have the master locally as you do. When I make a change on the script I first do "git commit -a" and then "git push". I am in the "columbo" forlder on my pc. If you add a new file you first have to tell git to add it: "git add ". You can always use "git status" to see what is tracked and what has changed.To examplify I created this small sequence for you :-)
hpbcadom#LUBUNTU32:~/columbo$ echo "Git example" > example_file
hpbcadom#LUBUNTU32:~/columbo$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add ..." to include in what will be committed)
example_file
nothing added to commit but untracked files present (use "git add" to track)
hpbcadom#LUBUNTU32:~/columbo$ git commit -a
[master d799b3a] to help I hope
1 file changed, 1 insertion(+)
create mode 100644 example_file
hpbcadom#LUBUNTU32:~/columbo$ git push
warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
git config --global push.default simple
When push.default is set to 'matching', git will push local branches
to the remote branches that already exist with the same name.
In Git 2.0, Git will default to the more conservative 'simple'
behavior, which only pushes the current branch to the corresponding
remote branch that 'git pull' uses to update the current branch.
See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)
Username for 'xxxs://github.com': caroldomokos
Password for 'xxxs://caroldomokos#github.com':
Counting objects: 4, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 288 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To xxxs://github.com/caroldomokos/columbo
dadf5af..d799b3a master -> master
I hope it helps :-)
If I execute git review git shows me "Working tree is dirty" error.
I made a commit and I sent to review. After that I update the branch from the upstream using git pull. Now I need to modify the previous commit message, so, there are my commands:
1) git reset <id-of-the-commit-to-modify>
2) git commit --amend
vim was opened to modify my commit. But here appears information about my commit and others commits as well and I don't know why. However, I modified the commit message and write/close vim.
3) git review
This command raise this error:
Errors running git rebase -i remotes/gerrit/master
doc/source/configuration.rst: needs update
doc/source/developing.rst: needs update
tools/sample_data.sh: needs update
Working tree is dirty
What I doing wrong?
git reset <id-of-the-commit-to-modify> without a mode option is defaulted to --mixed . This is what is said on the reset in the manual
--mixed
Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.
This basically means your index has been reset, but not your working files. So all files that you pulled from upstream are still left in your working tree.
You should use git reset --hard <id-of-the-commit-to-modify> This will reset your index and remove the files that came with your upstream pull. You can then amend your commit and send it for review.
once a change was pushed to Gerrit, then it can be fetched directly. On the Gerrit review board you can find the chekcout command for each patchset, something like this: git fetch ssh://ebalbar#gerrit.ericsson.se:29418/TCC/TitanSim refs/changes/86/129686/5 && git checkout FETCH_HEAD Then, you can amend the commit as usual, and push the new change again. AFter that checkout your local branch and reset it with the remote branch: git reset --hard origin/<remote_branch> also a nice answer how to modify a commit which was pushed directly.
I was using a github repository from a previous developer.
I am the only coder on this project, so I forked the project over to my own github repository.
Now I would like to commit soley to my repo.
Unfortunately, I realized that I never changed my .git/config , so I was still committing to the old repo. I just changed it to the appropriate url, and when I type :
$> git status
It returns :
=> Working directory clean.
But I know its not because I have several commits I've made. So my local box has different code then what it is pointed to on my repository.
My question is this. Obviously I'm halfway through the process of doing this. Do I need to re-fork to update, and then I'm good. Or is there a special command I need to run to let my local box know its 'git status' command is targeting a new repo to compare itself to? Equally, am I missing something else very important :D ?
Thank you everyone.
You can use git remote to manage your remote
rename origin
git remote rename origin old_origin
add a new origin
git remote add origin git://github.com/my/forked/repo.git
git fetch origin # will create all the remote branches references
# in your local repo
You can also easily setup a new upstream for your current master branch (git 1.7 and more):
git branch --set-upstream master origin/master
The "nothing to commit (working directory clean)" message of git status won't prevent you to push.
After changing the origin, you should see:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by xxx commits.
#
nothing to commit (working directory clean)
That means you have some commits to push to your new origin.
Note: "git remote"(man) rename failed to rename a remote without fetch refspec, which has been corrected with Git 2.39 (Q4 2022).
See commit 5a97b38 (22 Sep 2022) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit 20a5dd6, 10 Oct 2022)
remote: handle rename of remote without fetch refspec
Reported-by: John A. Leuenhagen
Signed-off-by: Jeff King
We return an error when trying to rename a remote that has no fetch refspec:
$ git config --unset-all remote.origin.fetch
$ git remote rename origin foo
fatal: could not unset 'remote.foo.fetch'
To make things even more confusing, we actually do complete the config modification, via git_config_rename_section().
After that we try to rewrite the fetch refspec (to say refs/remotes/foo instead of origin).
But our call to git_config_set_multivar() to remove the existing entries fails, since there aren't any, and it calls die().
We could fix this by using the "gently" form of the config call, and checking the error code.
But there is an even simpler fix: if we know that there are no refspecs to rewrite, then we can skip that part entirely.
git status only shows you the status of your working directory, not the entire repository. It seems like you only need to change the remotes that git push and git pull use by default. Open up .git/config and find your branch.<branch> entries and change them, as well as your remote.<remote> entries. For example, your master entry may look like this:
[branch "master"]
remote = origin
merge = refs/heads/master
Just change remote to reference your (forked) remote.
Also, your remote entry may look like the following:
[remote "myremote"]
url = git://github.com/me/repo.git
fetch = +refs/heads/*:refs/remotes/origin/*
You can add a push entry so that your master branch is pushed by default:
[remote "myremote"]
url = git://github.com/me/repo.git
fetch = +refs/heads/*:refs/remotes/origin/*
push = master
In whole, but I should include it in this answer. Is that before hand I manually altered my .git/config to include my new repository url. That's why I didn't have to rename or add any origin as Von suggested.
Then I just guessed this and performed
$> git fetch origin
Which returned
From git#github.com:gotoAndBliss/hq_channel
17326ca..043d395 master -> origin/master
* [new branch] panda_streaming -> origin/panda_streaming
+ 6ec9bf8...becbcc6 testing -> origin/testing (forced update)
Then on git status I got
# On branch testing
# Your branch is ahead of 'origin/testing' by 9 commits.
I git pushed origin testing, and I think I'm on target now.