WebStorm tries to push my project to an account that does not exist anymore. How do I change it? I have already added the new account to WebStorm and it still tries pushing to the old account.
You can change it in Settings>Repositories.
Setting>General>Repository name>rename
The entry highlighted on the screenshot is the commit author. This information is written in the commit, and is not related to the account that is used to push the change.
Author is determined by git configuration. You can check and change it using CLI - git config user.name and git config user.email
To change the author of the commit in question you need to re-do the commit.
Make sure git user is correctly set in git config, then undo the commit, and commit changes again.
To push, WebStorm will authenticate using the account configured in Settings | Version Control | GitHub, or according to the ssh config if ssh access is used.
Related
Is it possible to connect a project from IDEA to Gitlab?
There are no problems with GitHub, you specify a github account, then VCS-> Import into and it creates a project in your account. But with GitLab I don't see such a possibility. Maybe there is some way?
Or just manually throw it in there?
If all you want to do is create a project, that is as simple as pushing the repo. In GitLab, you don't have to create the project in the UI first. You can simply push directly to a project namespace that does not yet exist. The project will be created when you push to it.
Therefore, all you have to do is configure your git remote per usual, then push.
git init
git checkout -b main
echo "# My Project" > README.md
git add README.md
git commit -m "initial commit"
git push --set-upstream git#gitlab.com:namespace/myproject.git main
Then you'll see the message from the remote in the git console log
remote: The private project namespace/myproject was created.
In the JetBrains IDEs, you can simply configure the remote and push.
You only have define the remote ahead of time in the terminal. For example:
git remote add origin git#gitlab.com:namespace/project
Then in the IDE, when you go to push, you'll see the ability to push to the new remote/branch.
Then you'll also note in the git tab console you'll see the message from the remote that the project has been created.
Full integration for GitLab hasn't been implemented yet, but there is a feature request for that:
https://youtrack.jetbrains.com/issue/IDEA-109294
Meanwhile, you can create a repository in GitLab, then press Cmd/Ctrl+K and Click "Commit and push". In Push dialog there will be "Define remote" button - click on it and paste URL to GitLab's repository.
If it's HTTPS then you'll be prompted with username and password - enter them, alternatively you can enter Username and Personal access token (in password field)
I've run into this serious error while committing, and created a bug report.
I keep getting this error on TortoiseGit operations:
git did not exit cleanly (exit code 128)
I've reinstalled the program, rebooted, and tried to clone a fresh repo from github - nothing seems to work. I also deleted %appdata%\Tortoise git folder ... I'm at a loss now. Any advice on how to proceed?
It's probably because your SSH key has been removed/revoked. Make a new one and add it to your GitHub account.
for me I simply had to add configure my git username and email with the following commands:
git config --global user.email "you#example.com"
git config --global user.name "Your Name"
If you're running windows 7:
I was trying to decide the best way to do this securely, but the lazy way is :
right-click the parent folder
click the "properties" button
click the "security" tab
click the "edit" button
click the group that starts with "Users"
click the checkbox that says "full control"
click all the OK's to close the dialogs.
I realize this might circumvent windows "security" features, but it gets the job done.
git-bash reports
fatal: Unable to create <Path to git repo>/.git/index.lock: File exists.
Deleting index.lock makes the error go away.
In my case a folder in my directory named as the git-repository on the server caused the failure.
Deleting index.lock worked for me
on win7 64:
git-gui gives a good answer: a previous git has crashed and left a lock file. Manually remove.
In my case, this was in .git/ref/heads/branchname.lock.
delete, and error 128 goes away. It surprises that tortoisegit doesn't give such an easy explanation.
In my case, it was because of the proxy. A proxy was needed in the corporate network and TortoiseGit / Git does not seems to automatically get information from Windows internet settings. Setting up the proxy address solved the issue.
For me, I tried to check out a SVN-project with TortoiseGit. It worked fine if I used TortoiseSVN though. (May seem obvious, but newcomers may stumble on this one)
In my case, I forgot to add git to the respository name at the end.
I did git revert a multiple times ,and it worked for me make sure un-check the files while reverting you need changes. Stash your changes and pull again.
I was having this same issue and I resolved it in the following way...
I have the NVIDIA "Tegra Android Development Pack" installed and it seems to also have a version of mysysgit.exe with it. TortoiseGit automatically found that installation location (instead of the standard git installation) and auto-populated it in the settings menu.
To correct this, go to: "Settings -> General" and there is a field for the path to mysysgit.exe. Make sure this is pointing to the correct installation.
An quick solution would be to create a new local directory for example c:\git_2014, In this directory rightklick and choose Git Clone
make sure the username and email fields are not empty in the config file. and try to clone to an empty directory. these steps worked for me.
although, it is a very old thread, recently I got this error, and in my case, the link was broken. When the link to GitHub was fixed, it worked.
What has worked for me:
Removing all offending branch related files from all folders in .git\ref and .git\logs
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).
I've configured my hg repository according to the docs described here:
MultipleCommitters.
However, when I execute "hg update -C" to recreate the working copy locally, the file permissions have changed such that it eventually causes errors on push when other developers attempt to commit changes. Supposidly, when configured properly, hg update will preserve file permissions. Yet it doesn't appear to be doing so:
-rwxrwxr-x 1 root mercurial 2948 2010-06-24 15:27 .hg/store/data/src/public/index.php.i
vs. (actual source file, after deleting the working copy and recreating with "hg update -C")
-rw-r--r-- 1 root mercurial 820 2010-06-28 12:07 src/public/index.php
How can mercurial be configured such that when users create new files or modify existing files, the group and it's permissions are preserved?
UPDATE
2010.06.28
Here is a sample of the errors I'm seeing:
remote: resolving manifests
remote: getting src/configs/application.ini
remote: abort: Permission denied: /hg/repo/path/src/configs/application.ini
remote: warning: changegroup hook exited with status 255
remote: calling hook changegroup.notify: hgext.notify.hook
I had this same problem and solved it by setting the sticky bit on the remote repo directory.
chmod +s `find . -type d`
That will solve the problem that the OP ran into.
Which method exactly you've used? Describe more what is your setup.
Yes, mercurial does remember file permissions on commit. When you do hg update -C, it will recreate files with permissions that were set on last commit.
Your error message seems to be telling that repository files on repository server have wrong permissions/owner, so you cannot modify them with hg push. This could be because someone commited and pushed files as a different repository server user.
I would reccomend shared ssh method ( https://www.mercurial-scm.org/wiki/SharedSSH ): you set up separate user account for repository management, add developer's ssh public keys (you should restrict them to be used only with mercurial with specific repositories) and then use ssh://hguser#server/path/to/repository as an url.
BTW: by default mercurial doesn't run any hooks if a user used to do push/pull is not in trusted list. See trusted section in man hgrc.
BTW2: don't run any regular software as a root. use normal account for that.