Basically, I would like to revert a central SVN repository back to a previous commit, kinda like this:
svn update
svn merge -r 150:140 .
svn commit -m "Rolled back to r140"
But I'm using git-svn and cannot seem to find an equivalent.
I've tried setting everything up locally on a new branch by checking out an earlier commit that was an ancestor of trunk (the current commit of the central repo). I made a few additional changes and now I cannot git svn rebase or git svn dcommit without getting an error from SVN.
I tried checking out that same commit without making the additional changes and then running git svn dcommit, this says it is committing to the central repo but doesn't actually seem to do anything.
How do I go back to a previous commit and then start making new changes?
Your task is essentially to reset your git HEAD into the state of r140, but in a way that would allow a straightforward git svn dcommit.
One way of doing this:
# checkout git revision of the desired state
git svn find-rev r140 | xargs git checkout
# reset HEAD to the revision 150, assuming it was the latest svn commit in trunk
git reset trunk
git add -u
git commit -m "Rolled back to r140"
git svn dcommit
You could also take a look on thread Revert multiple git commits
Related
I have done some incorrect commits using gerrit in eclipse. Now, I want to delete my commit history.
*Doing hard reset to the original head i.e. before any commit does not work.
Open command prompt or git bash.
git revert HEAD~1..HEAD
It will checkout the previous commit. It will get you in to a state called detached head. create new branch from this point and continue your work,
if the commit is a merge add -m flag
git revert -m HEAD~1..HEAD
I am using eclipse, git and github. A friend of mine forked my github repo and changed some code. There was a pull request, I accepted the changes to my github repo. Now I tried to commit my own files and I am not able to 'commit and push'. As you can see in my screenshot there are no visible differences in the file. What procedure will solve this conflict?
Assuming your friend's work got merged into master and you are on branch your-feature-branch then:
git checkout master
git pull
git checkout your-feature-branch
git rebase master
will attempt to rebase your work on top of master, which already includes your friend's changes. The rebase procedure will process your commits one at a time and inform you of any conflicts which you can then resolve. Each file with conflicts will have conflict markers that tell you the changes introduced by each branch. After resolving the conflicts stage your changes then do
git rebase --continue
Repeat until rebase finishes. If at any point you become confused you can always abandon the rebase with
git rebase --abort
Once your work is rebased push your-feature-branch to origin, open a pull request, then merge.
I got the same issue sometimes, without a visible reason. Using a git rm on the directory containing the bad file, followed by a git reset --hard solved the issue for me.
git rm --cached -r DIRECTORY
git reset --hard
I am currently making a project in eclipse.I made changes in head branch and as well as in master branch.I want to merge those changes and push them to remote repository.Please tell me the correct steps so i merge both branches and push the changes to remote repository without getting non fast forward warning.
I am currently making a project in eclipse.I made changes in head branch and as well as
in master branch.
Normally when people refer to "head" they are talking about HEAD, which is not actually a branch but a reference to the "tip" of the currently checked out branch. So if you
git clone foo
cd foo
git checkout bar
assuming bar is a branch, then HEAD would refer to the "tip" or last commit of the bar branch.
If you are getting a non fast forward warning on a push, changes have been made to the remote repository. You to bring those changes into your local branch before you can push.
This is because git requires merge conflicts be resolved in the local repository, not the (usually shared) remote repository. To bring those changes to your local repository you will need to execute a pair of commands; git fetch ... and git merge ... results in a merge commit, which some prefer -- while git fetch ... and git rebase ... if merging the changes without a merge commit is preferred. Note that git pull ... is the same as git fetch ... and git merge ... and git pull --rebase ... is the same as git fetch ... and git rebase ....
Which ever way your prefer, once you get the changes to your local repository (and resolve any conflicts there may be) you will be ready to push.
I created a local git repository, and I push changes from it to a gitosis remote that I created with
git init my_git
git remote add origin git#server:my_git
... various adds and commits
git push origin master:refs/heads/master
Now, I edit and commit changes locally in eclipse, and when I commit, I see (using qgit) that it moves my master branch to that version.
However, it also shows me that origin/master is at the previous version.
git status on command line shows me everything is up to date:
$ git status
# On branch master
nothing to commit (working directory clean)
I can see the differences in versions with
git diff origin/master
If i do git push on my command line, then qgit shows me the origin/master branch is now at same place as my master.
I can't work out how to configure the "remote / push" or "remote / configure push to upstream" dialog in eclipse to do the same thing as a command line git push to move the origin/master to the same level as the master.
I always have to do the command line push to make the origin/master come up to the same place as master.
Q1. Can anyone tell me how to do this in eclipse?
Q2. What is the command line version of git push doing that the eclipse version doesn't do?
Q3. Are my assumptions that master is my local HEAD pointer and origin/master is the remote server's view of the current HEAD correct?
Going by the relevant part of egit's documentation you can either:
click the "Add all branches spec" button, to push all of your local branches to ones with the same name in the remote repository, or
(the much safer option) just select master under both "Source ref" and "Destination ref" to only push your master branch
The remote-tracking branch origin/master is usually updated by git fetch (which is part of what git pull does), but with command line git, the remote-tracking branch is also updated on a successful push to the branch in the remote repository that's being tracked. It's possible that Egit, being based one of the pure Java implementations of git, JGit, rather than the command-line tools, doesn't update origin/master on a successful push in the same way. If that's the case, you can just do a fetch to update origin/master.
Update: It seems that this is a known bug in EGit (not the underlying JGit) - the bug report is here:
Push does not update remote tracking branch
An update to this, I was using eclipse Helios, and I've upgraded to Indigo, with the latest version of egit, and the fix appears to be active, as I'm no longer having to pull after a push.
This is my current git-svn workflow:
git checkout -b feature master
# hack commit hack commit
git checkout master
git svn rebase
git merge feature
git svn dcommit
This usually works fine, git replays at the trunk all the commits from the local branch, and the only 'lost data' are the original commit's timestamps, no big deal.
But it looks like today there was something different about the merge and dcommit that caused the commit message on the SVN repo to be simply "Merge branch 'feature'", maybe because the feature was 'smaller', with only 2 or 3 commits.
How can I avoid this to happen and ensure that all commits and commit messages from git are replayed on the SVN repo?
That comment should be the result of a dcommit of a git merge, as illustrated in "Is git-svn dcommit after merging in git dangerous?":
(master)$> git log --graph --oneline --decorate
* 56a779b (work, master) Merge branch 'work'
|\
| * af6f7ae msg 3
| * 8750643 msg 2
| * 08464ae msg 1
|/
* 21e20fa (git-svn) last svn commit
In other words, if those three "msgx" commits had been done directly on master, they would have been replayed (with their original comments) on the svn side.
But here, only the resulting merge commit gets replayed, with the "generic" comment on it.
You will need to rebase from the feature branch first:
git checkout feature
git rebase master
This ensures that when you merge into your master, you only get a Fast-Forward rather than an actual merge.
My flow is usually more like this:
git checkout master
git svn rebase
git checkout feature
<hack...hack...hack>
git commit
git rebase master
git checkout master
git merge feature
I just make sure to do an svn rebase and then rebase all my feature branches to keep everything nice and linear the way that SVN likes it.
Also, if you're not aware of it, there is the git svn dcommit --dry-run option. I always use --dry-run and count the number of commits to make sure that git-svn is going to commit what I expect.