I have a bash script that pulls and builds some source code. If I am on the master branch, it works as expected, however if I change to a different branch it says it is already up to date even if there are pushed changes. If I do a git pull outside the script from the cmd line, it pulls as expected.
deploy.sh
echo | git branch
echo "git pull ..."
git pull https://tech-dev:password#bitbucket.org/mycompany/pow-wow.git
Output
./deploy.sh
master
* spring3upgrade
git pull ...
From https://bitbucket.org/mycompany/pow-wow
* branch HEAD -> FETCH_HEAD
Already up-to-date.
Question
How do I get it to pull from the branch I am currently on in the bash script?
why it doesn't work
If you are pulling using an explicit URL (as displayed in your question) :
there is no default refspec, so only the remote HEAD (the default branch) is fetched
there is no default "remote branch" configured for your checked out branch, so git pull will merge in whatever that default branch points to (ie: it will try to merge origin/master, not origin/spring3upgrade)
how to fix it
The simplest way is to define a named remote (e.g: origin), let git set up its default configuration, and have named remote tracking branches:
git remote add origin <URL>
git fetch
# for branches that already exist locally:
git switch <branch>
git branch -u origin/branch
# for remote branches not checked out locally:
git switch <branch> # will automatically take 'origin/<branch>' as a base,
# and set it as the upstream branch
If you have a special need which requires to not name the remote: you may provide the refspec you need on the command line, probably:
# pull the branch which has the same name as your local branch:
git pull <repo> "$(git branch --show-current)"
You need to provide specific credentials to access your remote. There are many ways to do that :
a pretty common way is to go through ssh: create an ssh key, configure your central server to accept the public key for a CI (you choose the name ...) dedicated user, and set up your builder agent to access your repo through ssh with that key
or using https, set up a credentials manager (see the link your posted in your comment, or git help credentials), or the many http.* settings in git help config
Related
Branch "abcd/child" is created from "abcd/master" . Changes are made to "abcd/child" and meanwhile "abcd/master" also have added changes. Now how to make sure the latest changes are pulled from "abcd/master" is available in "abcd/child" using git commands in git bash?
Assuming abcd is the name of your remote, here's how I'd do it:
git checkout child
git pull
git merge abcd/master
git push
When you checkout child, it'll probably say "set up to track remote abcd" or similar.
The git pull command does two things: It fetches all updates from the server (on all branches) to your local git repo, and it updates your branch to match what's on the remote.
The git merge abcd\master means to specifically bring in all of the commits that are on the remote's copy of the master branch. That's important because you may not have updated your local master to have all those commits.
Note also that you might get conflicts in the git merge if both abcd and master have edited the same sections of the same file. There's lots of help in resolving git merge conflicts.
Also: You want to make sure everything works after the merge. It's possible that the changes on master broke an API that you were using, so you may need to make edits to deal with that.
Update: My assumption about abcd being the name of the remote is wrong.
First, get the name of your remote with the git remote command. Mine goes like this.
git remote
origin
So I only have one remote, and I call it origin. That's pretty common. If you've got more than one remote, it'll be trickier.
So, with "origin" as the remote it goes like this:
git checkout abcd/child
git pull
git merge origin/abcd/master
git push
Obviously substitute the name of your remote if it's not origin.
Same caveats apply about conflicts and making sure it works.
I am writing a bash script for automatic git interaction. The issue is that once I run my script with the changes, I am able to push correctly, but on next run, git fetch does not show me the latest commits(on remote branch) which I did using the script.
I am able to see my change commit of my script on our repo(gitlab), but if I run the script again with other commit, during the fetch part, I dont see any ref updates
branch HEAD -> FETCH_HEAD
If I check manually doing git fetch origin command, it updates the refs correctly, but the git fetch ${_gitUrl} does not update the refs of my remote. I am using the gitUrl constructed because I dont want a uName and password prompt, and I did not want to use ssh here.
How can I use git fetch with my https url to reliably update my remote refs? Please help.
My git push is: git push ${_gitUrl} "${_branchToPush}:${branchName}"
My git fetch is: git fetch --prune "${_gitUrl}"
I have also tried git fetch "${_gitUrl}"
My gitUrl is: https://uName:pwd#repo/project.git
My git config --get remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
Checking the HEAD after fetch: git log origin/${branchName}
How can I use git fetch with my https url to reliably update my remote refs?
What remote refs? It seems you think that git fetch/pull/push "${_gitUrl}" makes git match the URL back to remote name? No, git doesn't do that.
One reason is efficiency. Why spend time mapping URL to remotes?
Another reason is unambiguity. What if there are multiple remotes with the same URL? Git allows that. To what remote Git should map the URL in that case?
So no, Git doesn't do that. Name your remote yourself.
I found a work-around for this. As pointer out by #phd that git does not map url to remotes, meaning on git fetch ${_gitUrl} will not update my remotes(I was assuming origin/*) will be updated.
For this to work, I mapped the remote name(origin) with the url:
git remote set-url origin ${_gitUrl}
git fetch ${_gitUrl}
This is correctly fetching the remotes from url. I dont know if this is best solution, as now the password is stored from the url and visible on git config --list.
I have some projects I would like to upload on my bitbucket private profile. I performed the following steps but I get an error.
Convert my project to git with: git init
Next:
git add
git commit -m "some message"
I created a bitbucket repository and version control system is GIT.
I then type this (of course with real account name and reponame and repo owner):
git remote add origin https://<repo_owner>#bitbucket.org/<accountname>/<reponame>.git
Finally,
git push -u origin master
I did all of this and my terminal gives me this error:
To https://bitbucket.org/milosdev_me/lfs.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'https://milosdev_me#bitbucket.org/milosdev_me/lfs.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Try:
git push origin master --force
This works for me.
Your master branch has some code that you don't locally have, and to prevent you from conflicts, it doesn't let you to push further changes, before you have them locally. To resolve this, pull all the changes to your local repository (your project):
git pull origin master --allow-unrelated-histories
After that, you will have all the code that is available on your master branch.
NOTE: Be careful, pulling the code from remote branch might mess up all the changes locally. Make sure to save those changes somewhere, or create another branch locally where you will pull your origin master branch, so it doesn't mess up your changes.
Your issue is that you have different things between your local repository and your git repository (probably a readme file that you created automatically), so you have two options:
use git pull origin master, with this command, you will pull from your git repository, but it will cause a merge conflict, which you have to resolve using an IDE (recommended to beginners) or through cmd.
use git push origin master --force, this way, you will force your push from your local repository to your git repository, ignoring any merge conflict by overwriting data. I'm not sure, but I think it will overwrite all git repository data with you local repository data (which is what you want).
Adding --force option is a bad idea
Either rebase it or pull the code, merge it and push it.
git pull --rebase origin master
git push -u origin master
Your remote repository and local repository have differences, something new in remote repository. So for pushing you need pull changes, from remote, previously. Try do:
git pull
git push -u origin master
The issue is because your remote repository and local repository have differences.I had same issue and i tried all the above mentioned solution but nothing worked for me.
For me the scenario was :- I already had my branch in remote repository.If you have the same scenario then follow below steps:-
run command 'git pull'
delete branch from local repository
checkout that particular branch using "checkout as a new local branch" from
the Remote repository.
run command 'git branch -u <your_branch_name>'
run command 'git push or git push --force'
or you can try directly from step 4 first , if it does not work then follow entire steps.Hopefully it will help someone.
If you have your bitbucket account linked to jira.
(this answer will work for you, only if you have your jira account linked to bitbucket)
I was having the same problem trying to push my current branch with the origin.
for example:
my branch name was:
feature/PREFIX-000-new-name-branch.
previous commit:
git commit -m "Write your commit here"
so far it was not working.
you have to mentioned the ticket name in the commit.
if you have made the commit, make an --amend to rename your commit and retry it.
git commit --amend -m "PREFIX-000 Write your commit here"
try the push again.
If you are using BitBucket, this issue occured when I tried to push to a branch but that branch has writing disabled via the repository settings.
if you have already created a project locally and you want to upload it to git,
you will then need to do:
git status to see the changes you need to upload
git add . to add those changes to your repo
git commit -m "" to add a commit message
git push origin master
that way I solved the very same problem I
was having.
it might be a configuration issue
I fixed this issue after updating the global user.email value with my email
git config --global user.email my#email.com
Note: You need to delete the previous commit because it had the wrong email in the commit
I need to extend a given tool with a Bash script that is supposed to work with Linux and MacOS. The script gets 2 parameters:
A repository location (file system, ssh, http(s), ...)
A commitish, e.g. branch, tag, commit hash
I have no influence on the parameters
The result of the script's run should be that
the repository is cloned to a fixed destination (always the same for one repository)
the repositorie's working tree should correspond to the latest state of the comittish (e.g. if it was a branch the tip of that branch)
If the repository does not (yet) exist locally, the procedure is as simple as
git clone $REPO_SOURCE $REPO_DIR
cd $REPO_DIR
git checkout $REPO_REF
My question: Consider a repository is already cloned to /repos/foo. After an obvios git fetch, how to I update that repository to the provided $REPO_REF?
If $REPO_REF was a branch, a git checkout $REPO_REF && git pull should work
If it was a commit hash, there was no update needed (just git checkout $REPO_REF?)
If it was a tag, then the tag might have been moved on the origin, how to handle this?
How to handle other edge cases?
Is there a simple reset-repository-to-this-commitsh way, so the repository behaves just as if it was freshly cloned?
Side nodes:
The same repository might be used with different commitish's, but only sequentially: It is guaranteed that the script isn't invoked more than once at the same time
All external changes to the repository might be always discarded without notification
While deleting and cloning the repository would work, it is impractical due to their sizes and it being an ugly solution
No (git) changes are needed, so checking out a detached head is okay
The only totally-foolproof yet convenient way is to have the other Git (the one you might be cloning, but might not) resolve the name for you. Then you have a hash ID and a hash ID is universal.
If the name is a branch or tag name, you can use git ls-remote to achieve that step. If it might be some other formulation (e.g., master~13) you're out of luck here. So, if you need to resolve the name locally:
If tag discipline is obeyed, no tag will ever move. This means that if you have an existing clone that has the tag, it has the right tag, and you're OK here, and if you have an existing clone that doesn't have the tag, you can add the tag and resolve it.
If tag discipline is not obeyed, you'd have to delete and re-create the tags (yuck), or else re-invent remote tags: copy their refs/tags/* names to your refs/rtags/<remote>/* name-space. See Git - Checkout a remote tag when two remotes have the same tag name.
If you have a branch name or something relative to a branch name, turn the branch name into your own remote-tracking name (e.g., replace master~13 with refs/remotes/origin/master~13) and resolve it.
In any case, you now have a hash ID and can use detached HEAD mode.
Using a "standard" git clone you could to this:
# cleanup old cruft
git reset --hard HEAD
git clean -fdx
# detach from current branch (if on any)
git checkout --detach
# delete all local branches
git for-each-ref --format="%(refname:strip=2)" refs/heads |xargs -r git branch -D
# fetch and update all remote refs and tags
git fetch --force --all --tags --prune --prune-tags
# checkout
git checkout "$COMMITISH"
That way you can rely on git checkout to do its job as usual and you don't need to replicate any of its heuristics, shortcuts etc.
Here is the problem:
Whenever I do
$ git pull 'https://github.com/username/reponame.github.io.git'
followed by the url I get no problems but when I do
git pull origin master 'https://github.com/username/reponame.github.io.git'
followed by the url it returns
fatal: Invalid refspec 'https://github.com/username/reponame.github.io.git'
What does this mean and how should I go about fixing it?
If you have already established remote-tracking branches (i.e. git clone does this automatically) and want to use git pull with the intention of grabbing and merging the latest commits for the current branch off the remote repository, I believe that executing the following will suffice:
git pull
To achieve the same effect with the inclusion of a refspec (unnecessarily long-winded):
// Pulls the remote 'master' branch down to the local 'master' branch
git pull origin master:refs/remotes/origin/master
You are receiving that error because the provision of a URL is not how the refspec is formatted.
For further details on how the refspec works and its syntax, consult this chapter from the wonderful Pro Git book. Hope that helps!
If you'd like to pull the branch "master" from a repo using its explicit URL, then the command to call would be:
git pull https://github.com/username/reponame.github.io.git master
Because "origin" is just a name of a so-called "named remote" which is sort of a configured alias for a repository which allows you to not type that repo's URL each time you access it.
The canonical call to git pull is:
git pull [<repo> [<refspec> ...]]
Where parts in [...] are optional — see the manual page.