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.
Related
So, I have a number of Wordpress sites managed with a Git repository, all of which are branches off of a central upstream Git repository. I recently applied a bunch of updates to the parent repo, but one of the child website repos had a plugin updated to a different version and now throws up about 400 rename/rename conflicts. All of these conflicts are in an upstream plugin directory that would be safe to just resolve in favor of the upstream branch.
I want to do the following:
Ensure the upstream version of the files 'wins' the merge conflict (e.g. what the --theirs flag does with checkout)
Produce a mergeable history (If it's not safe for a coworker to type "git pull origin master" with an old repo, it's not an option. I'm religiously opposed to rebasing.)
Not restructure my Git repository (My hosting provider, Pantheon, will not install Composer dependencies at deploy time. Upstream plugins have to be part of the repo.)
Not get a repetitive stress injury (Has to be a reasonably small number of commands because I have to resolve these kinds of messes once a month or so.)
If I just type "git checkout wp-content/plugins/** --theirs", I get hit in the face with about 400 errors, and Git refuses to checkout the files. They look like this:
....400 or so errors omitted...
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-quick-edit-handler-710.min.js' does not have their version
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-quick-edit-handler-720.min.js' does not have their version
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-recalculate-710.min.js' does not have their version
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-recalculate-720.min.js' does not have their version
I categorically refuse to type 400 git rm/git add commands with each individual path included. git checkout --force is not an option, as --theirs and --force are mutually incompatible (for some reason). My current solution is to open Git GUI and manually right-click -> Use Remote Version and then click Yes... 400 times. I don't have to type the path at least but this is still time consuming.
How do I efficiently resolve a large number of rename/rename conflicts in favor of the remote repository?
Do you want to just resolve the conflicted files in favour of the remote, or just take a whole tree as it is in the remote?
For the latter, you could do this:
Just accept the files as-is with conflicts. git add . or similar
Commit the merge.
rm -Rf path/in/question
git checkout origin/branch -- path/in/question
git commit --amend -a
For the former, it's probably something pretty similar
Just accept the files as-is with conflicts. git add . or similar
Commit the merge.
Find files with conflicts. e.g. grep -r -l '>>>>' path/in/question > /tmp/conflicts.txt
Delete the files with conflicts, check out the desired versions, and amend the commit in a similar means to the above.
(If there are files/paths with spaces in them, small adjustments to the above commands may be necessary. I've given the simpler versions for clarity.)
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
Say I have a repository repo:
library(git2r)
repo <- repository(".")
In this repository is a subdirectory R, with files a.txt, b.txt and other files that I'm not interested in. How can I use git2r to work out if there are unstaged changes in these files? I've looked at summary(diff()), but that works on the level of the whole repo.
Essentially, what I'm trying to do is replicate the effects of the git command:
! git diff-index --quiet HEAD -- file
Where if there are changes in the file, then return false. While I could use a system command, there's no guarantee the user has git in their path and so the command would fail.
Is there a way to replicate the git functionality I'm looking for?
This issue is solved in the latest development release of git2r.
There is now an all_unstaged option to status:
> status(repo, all_untracked = TRUE)
Untracked files:
Untracked: untracked/a.txt
Untracked: untracked/b.txt
I've gotten the OpenERP source using the instructions.
I've moved the whole source directory somewhere else in my home.
Now, when I try to pull changes it throws errors:
shahar#shahar-desktop:~/src/openerp⟫ make pull
# update all trunk branch
for i in addons client oldweb web server; do [ -d $i ] && (cd $i && bzr pull && cd ..); done
bzr: ERROR: Not a branch: "/home/shahar/src/openerp/addons/.bzr/branches/origin/trunk/
/".
bzr: ERROR: Not a branch: "/home/shahar/src/openerp/client/.bzr/branches/origin/trunk/
/".
bzr: ERROR: Not a branch: "/home/shahar/src/openerp/web/.bzr/branches/origin/trunk/
/".
bzr: ERROR: Not a branch: "/home/shahar/src/openerp/server/.bzr/branches/origin/trunk/
/".
make: *** [pull] Error 3
2 shahar#shahar-desktop:~/src/openerp⟫
It isn't the make script that's at fault:
2 shahar#shahar-desktop:~/src/openerp⟫ cd server/
shahar#shahar-desktop:~/src/openerp/server⟫ bzr pull
bzr: ERROR: Not a branch: "/home/shahar/src/openerp/server/.bzr/branches/origin/trunk/
/".
3 shahar#shahar-desktop:~/src/openerp/server⟫
The paths that are printed above seem to be stemming from each repository's .bzr/branch/location file.
I've discovered this file when I tried to fix this issue by using grep -rI /home/shahar. And then I've changed the path within this file from what it was to what you see now. I thought that it could perhaps fix the issue but it didn't. I still got the same errors (with the new paths).
I couldn't find any info about moving bzr repositories in the whole of the interwebs with Google or in StackOverflow.
Thanks.
The installation script you used seems to use the bzr-colo plugin to manage colocated branches.
The bzr-colo manual indicates that because absolute pathnames are used to store references to branches, when a colocated workspace is moved on disk, the link from the checkout to the current branch gets broken.
This can theoretically be fixed by running bzr colo-fixup in the broken branch directory, however it does not seem work very often (in my experience).
In that case the manual recommends running this command to re-force a branch switch:
bzr switch --force .bzr/branches/<current branch name>
According to the output of your commands, this should be:
bzr switch --force .bzr/branches/origin/trunk
for you.
You do not even need to edit the .bzr/branch/location first, as it will be correct after the switch. This has always fixed the situation for me.