I've corrupted one file and I'd like to revert it back. My project is using git-svn.
So how can I revert this one particular file? Or even better if I could view whole change set of this file.
Detailed steps would be appreciated.
git revert SHA1_OF_FAULTY_COMMIT
add back the changes but don't commit
git cherry-pick -n SHA1_OF_FAULTY_COMMIT
Modify what needs to be modified, e.g.
git reset HEAD file_that_should_not_have_been_modified
Commit
git commit -m "to_be_merged"
Squash the two commits, put a meaningful comment.
git rebase -i HEAD~2
Review your changes, it should only contains the modification on the single file you:
git show
You can now push that to svn
git svn dcommit
Related
Normally I open a bash prompt inside my Test folder. I then git add, commit, and push origin the file and it goes into my Test folder in bitbucket. Now somehow my Test folder instead of showing .../Test (Development), it shows another repo, .../Test (Review). I do not know why it changed. How can I get (Review) to be (Development)?
In git there are pretty much three stages. When pressing git status you probably get a similar few to this with many more files:
# On branch review
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: file.txt
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: file2.txt
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# file3.txt
file.txt on top has staged changes. These will go into the next commit when you do git commit.
file2.txt has unstaged changes. This file is tracked in the repository but the changes will not be added to the next commit. Only if you git add this file will it get staged.
file3.txt is an untracked file. You have to add it with git add which will automatically put it into the staged area. Next time you will make changes to it you will find it in the unstaged area like file2.txt
from this situation git checkout master gives:
error: Your local changes to the following files would be overwritten by checkout:
file2.txt
Please, commit your changes or stash them before you can switch branches.
Aborting
This is probably what you get too. Git noticed that you made changes in the tracked file file2.txt but you didn't specify what to do with them. Similarly I suspect that you made changed to those '50 or so files' and now git doesn't know what to do.
Either add them to your commit and do a commit:
git add <files>
git commit -m "did some work"
or drop the changes:
git checkout <files>
Then they will return to the way they were at the last commit.
You can also add some files and drop others, or even do partial adds with git add -p.
Check the changes you made with git diff.
After this is resolved you can switch branches again with git checkout <branchname>.
Without more information on your branch structure in your bitbucket and your commit history it is hard to say what you can push to where.
How do I check the last date time of git pull request made, as I have done some changes in my repo and trying to push them but before it I used "git pull" but it says "Already uptodate", now I use "git push" but unable to push changes as it says "Everything up-to-date". While git status shows modified files in staged and unstaged.
What am I doing wrong ?
While git status shows modified files in staged and unstaged.
You need to commit the staged files first, in order to be able to push
cd /path/to/repo
git commit -m "Add files"
git push
I cloned a large SVN repository (nearly 8,000 commits) and it seems to be OK.
Since then, the commit messages of about 20 Subversion commit messages have been changed to correct a typo. This was done legitimately. However, git svn fetch does not pull the updated commit messages. It still displays the old outdated commit message.
Is there a way to fix this? Preferably in a clean way and without hacking my local git repository too much?
I've tried git svn fetch -r 1234 (where 1234 is a known revision number). But no luck.
from http://git-scm.com/docs/git-svn:
git svn reset
Undoes the effects of fetch back to the specified revision. This allows
you to re-fetch an SVN revision.
[...]
Follow reset with a fetch and then git
reset or git rebase to move local
branches onto the new tree.
So in your case, if revision 1234 is the first one that had its commit message changed, you would do
$ git svn reset -p 1234
$ git svn fetch
If anything is different, including the commit message, then the new commit is a totally different object, with a new SHA1, so as it says, you'll need to rebase any branches you might have onto the appropriate rewritten commit.
My typical git-svn workflow is:
git checkout -b story-xyz
git commit -a -m "work"
git commit -a -m "more work"
git checkout master
git svn fetch
git merge remotes/trunk
git checkout story-xyz
git rebase master (sometimes with -i)
git checkout master
git merge story-xyz
At this point I have my master and story-xyz branches pointing to the same commit, one or more commits ahead of remotes/trunk. Everything since remotes/trunk is in one linear history.
last svn commit [remotes/trunk] <--- work <--- more work [master, story-xyz]
I then run
git svn dcommit
I expected to see the commits between remotes/trunk and master become Subversion revisions, and end up with a single linear history with remotes/trunk, master and story-xyz all pointing to the latest revision, like so:
last svn commit <--- work <--- more work [master, story-xyz, remotes/trunk]
My Subversion revisions go in fine, but I end up with a two-branched structure. The common root of the branch is the Subversion HEAD before I committed. Both branches contain the same series of commits, in the sense that they contain the same diffs. The branch story-xyz is at the head of one branch, remotes/trunk and master at the other:
last svn commit <--- work <--- more work [master, remotes/trunk]
|
\- work <--- more work [story-xyz]
The git commits that I had before running git svn dcommit are on the lower branch (story-xyz), with my git commit messages, git user name and email, and git commit timestamps. The commits on the upper branch are new git commits. They use my Subversion username, the timestamp when I ran the dcommit, and the commit messages have the git-svn-id field appended to them.
This is all OK, and I can carry on working. The problem is that I look in gitk and see what looks like an unmerged branch story-xyz. It's pretty hard to tell the difference between a story branch that I have merged back into master, and one that I haven't. The most obvious way to spot it is the duplicate commit messages. I could delete the story-xyz branch, but that feels like I'm not using git properly and I've lost some of my history.
Am I missing something that would stop git-svn from doing this? Or is this just one of the ways that interacting with Subversion dilutes the power and freedom of git?
I don't think you're really missing anything. You might be doing some unnecessary work, though. In this case, you have two pointers to the "more work" commit, and you are asking git-svn to move one of them. The other one still stays where it is.
You don't really need the master branch. Git-svn doesn't care about what branch you are dcommiting. IIRC, it uses the first svn-remote it can find among the ancestors of the current commit.
I'll offer another version of the workflow:
git checkout -b story-xyz remotes/trunk
git commit -a -m "work"
git commit -a -m "more work"
git svn fetch
git rebase remotes/trunk (with -i, perhaps)
git svn dcommit
This should give you a tree without the extra branch. You need to be careful with fast-forward merges, though.
I understand how to initialize a git-svn repo, create a branch, do some work, merge branch, then use git svn rebase and git svn dcommit to push back to the svn repo. But between these two commands, how can you get a status of what is different between the two repos? Something like a git status that tells you that you have x number of files that have been changed.
Just do a diff between your branch and upstream.
git diff --stat git-svn/master..master
Obviously, you'll have to change the branch names to whatever's applicable for your setup.
The only real way I know is to run 'git svn dcommit -n' (or git svn dcommit --dry-run) which will usually give you output like this:
$git svn dcommit --dry-run
Committing to http://yourserver.com/trunk ...
diff-tree bc923cb54847fa340d094c3da1ebd66b8fb0e63e~1 bc923cb54847fa340d094c3da1ebd66b8fb0e63e
diff-tree a05c8be4af7f82dc4de5b4778e2b58203c75eebd~1 a05c8be4af7f82dc4de5b4778e2b58203c75eebd
And then you can 'git show bc923cb54847fa340d094c3da1ebd66b8fb0e63e' to view that diff.