I've run git init and made a mistake selecting the first branch. Now I want to rerun it to change the settings, but it never asks the first question again.
Which branch should be used for bringing forth production releases?
- develop
Branch name for production releases: [] develop
Which branch should be used for integration of the "next release"?
Branch name for "next release" development: [develop] ^C
Lymnaea:boxes (develop) $ git flow init
Which branch should be used for integration of the "next release"?
Branch name for "next release" development: [develop]
Production and integration branches should differ.
How can I undo the first init run so that I can set the branch to master?
In the end I found the answer in this question. It's not entirely a duplicate, so I'll leave this here for the next person that cannot find the right keywords.
git flow init -f # will force re-initialization
If you want to do it manually, you can use git config -e.
Related
Consider the following workflow:
make some changes
git add . && git commit -am 'update 1'
arc diff, now local and phabricator code review are in sync
make some further changes and git commit -a --amend --no-edit
arc land and the local amended (unreviewed) changes are happily accepted by Arcanist and gets merged to master.
Apparently, if I don't do --amend in step 4 and create another commit, arc land would fail complaining a mismatch. But I would like to configure Arcanist so that with --amend arc land can fail as well. Is this possible?
It turns out the arc command I am using is monkey patched by my employer and there is a bug in the patch.
I've a remote repository let's call it subrepo. I want to include it as subtree in local repository, let's call it mainrepo. I'll put subrepo under the path 'subrepofold/'.
I added as usually the remote using:
git remote add subrepo git#remote.subrepo.git
On mainrepo I've only a branch (master). I added and committed all:
git add --all
git commit -m "message"
git status
On branch master
nothing to commit, working directory clean
git diff-index HEAD --exit-code --quiet
Give me no output. Running:
git subtree pull --prefix="subrepofold" subrepo master --squash
I get the following message:
Working tree has modifications. Cannot add.
I know it seems to be the exact problem described here, but none of the replies seems to resolve the problem.
I am currently struggling with getting Rstudio to work with my git repositories. When I set up a new project and assign the git repository, the branch is set on Master and the commit, pull, and push buttons are all active. Everything works just fine. Then, at some point the branch is switched to (No Branch) and the commit, pull, and push buttons are greyed out (shown below). This happens to every single git project I make. Works at first then is greyed out.
I am still able to use git commands from Shell, but the GUI interface is not working.
I have spent some time looking through customer support forums and Googling the problem. One site that I found (https://www.r-bloggers.com/things-i-forget-pushpull-greyed-out-in-rstudio/) indicated that there is an issue with the configuration list. However, when I do git config --list, I find that I do have branch.master.remote=origin and branch.master.merge=refs/heads/master at the bottom of the configuration.
I also attempted a git push -u origin master, but that did not work either.
I use RStudio and github daily, and I would be so pleased if the GUI interface was working properly again.
I would be very grateful if someone could help me problem solve this issue.
EDIT: I am using OSX 10.9 Mavericks and Rstudio Version 0.99.903.
I had a similar problem with a repo I had already configured locally and pushed and pulled from/to it using CLI (although I didn't have the problem of being detached from a branch) and I solved it by doing the following:
Open your console and navigate to your repo
Make some commit
Make a push using -u (i.e. --set-upstream) flag, eg: git push origin master -u
Open Rstudio (or restart it if it was open while performing the previous step) and you'll see the push and pull icons are no longer greyed out.
Then, at some point the branch is switched to (No Branch) and the commit, pull, and push buttons are greyed out (shown below).
That is typical of a detached HEAD branch: see "Why did my Git repo enter a detached HEAD state?".
Revert to the command-line and check your git status.
You can easily recover from this by a checkout of a branch.
Or by forcing a branch to your current detached commit
git branch -f branch-name HEAD
git checkout branch-name
Then switch back to RStudio: all options should be available again.
As commented:
Tt turns out to be an RSA key issue.
The wrong key was in the Rstudio Config, which explains how Shell would work but not the Rstudio interface.
I just wanted to provide an update in case anyone in the future had a similar problem. While the answer provided earlier resulted in another temporary fix, I ultimately had to wipe my hard drive; reinstall the operating system; reinstall git, R, RStudio, and reconnect to my Github account before it would consistently work.
My solution may have been a bit overkill, but I have not had an issue with it since.
I had the same issue today and found this post. I am going to share how I solve it:
on terminal (Git) type the following:
$ git config --global user.name
(it should return your Github username)
if username isn't correct just type
$ git config --global user.name "correct_username"
then type
$ git config --global user.email
(it should return an email associated to your GitHub account)
I found a typo in my email and fixed it by typing
$ git config --global user.email "correct_email"
Then I added the origin (this you get it from GitHub)
$ git remote add origin https://github.com/my_username/my_repository.git
Then I setup the branch, most used ones are main and master, in my case it is main
$ git branch -M main
then I pushed from the terminal
$ git push -u origin main
after that my pull and push buttons are active.
I hope this can save some time for others.
I am seeing a strange behaviour, I don't know if it is a bug or a feature.
From machine #1 I do git reset --hard someCommit && git push -f. The reset is then propagated to all machine (I can see the change by doing a git pull or git logfrom another machine).
From machine #2 that runs JGit I perform: git.pull().call() but the reset is not applied and the files on disk are not changed. Also git.log().call() does not point to the reverted commit.
What am I doing wrong?
Like Tim described, you likely need to force fetch on the other computers.
The return value of PushCommand::call() will tell you if and why the push did not succeed.
To force pull in JGit, follow this example:
git.fetch()
.setForce( true )
.setRefSpec( new RefSpec( "refs/heads/someBranch:refs/remotes/origin/someBranch" ) )
.call();
git.reset()
.setMode( ResetType.HARD )
.setRef( "someBranch" )
.call();
I believe that the git.pull.call() command is being rejected. You executed the following commands:
git reset --hard someCommit
git push -f
The first one should completely reset the branch to someCommit. The second one force pushes the reset branch to the remote, rewriting the history of the branch in the process. The keyword here is -f which is short for --force.
Because you rewrote the history of this branch, other computers will no longer be able to do a simple git pull because the base of the branch has changed. So I believe that your JGIT call to git.pull().call() is failing with an error. To fix this, you need to "force" pull the branch on the other computers:
git fetch --all
git checkout someBranch
git reset --hard origin/someBranch
I'm running a Capifony deployment. However, I notice that Capifony's in-built commands are running against the previous release, whereas my custom commands are correctly targeting the current release.
For example, if I run cap -d staging deploy, I see some commands output like this (linebreaks added):
--> Updating Composer.......................................
Preparing to execute command: "sh -c 'cd /home/myproj/releases/20130924144349 &&
php composer.phar self-update'"
Execute ([Yes], No, Abort) ? |y|
You'll see that this is referring to my previous release - from 2013.
I also see commands referring to this new release's folder (from 2014):
--> Running migrations......................................
Preparing to execute command: "/home/myproj/releases/20140219150009/
app/console doctrine:migrations:migrate --no-interaction"
Execute ([Yes], No, Abort) ? |y|
In my commands, I use the #{release_path} variable, whereas looking at Capifony's code, it's using #{latest_release}. But obviously I can't change Capifony's code.
This issue against Capistrano talks about something similar, but I don't think it really helps, as again I can't change Capifony's code.
If I delete my releases folder on the server, I have a similar problem - #{latest_release} doesn't have any value, so it attempts to do things like create a folder /app/cache (since the code is something like mkdir -p #{latest_release}/app/cache).
(Assuming I don't delete the current symlink and the release folder, the specific error I see is when it fails to copy vendors: cp: cannot copy a directory, /home/myproj/current/vendor, into itself. However, this is just the symptom of the bigger problem - if it thinks the new release is actually the previous one, that explains why current also points there!)
Any ideas? I'm happy to provide extracts from my deploy.rb or staging.rb (I'm using the multistage extension) but didn't just want to dump in the whole thing, so let me know what you're interested in! Thanks
I finally got to the bottom of this one!
I had a step set to run before deployment:
before "deploy", "maintenance:enable"
This maintenance step (correctly) sets up maintenance mode on the existing site (in the example above, my 2013 one).
However, the maintenance task was referring to the previous release by using the latest_release variable. Since the step was running before deployment, latest_release did indeed refer to the 2013 release. However, once latest_release has been used, its value is set for the rest of the deployment run - so it remained set to the 2013 release!
I therefore resolved this by changing the maintenance code so that it didn't use the latest_release variable. I used current_release instead (which doesn't seem to have this side-effect). However, another approach would be to define your own variable which gets its value in the same way as latest_release would:
set :prev_release, exists?(:deploy_timestamped) ? release_path : current_release
I worked out how latest_release was being set by looking in the Capistrano code. In my environment, I could find this by doing bundle show capistrano (since it was installed with bundler), but the approach will differ for other setups.
Although the reason for my problem was quite specific, my approach may help others: I created an entirely vanilla deployment following the Capifony instructions and gradually added in features from my old deployment until it broke!