I've unintentionally committed some confidential files to a bzr branch. What's even more sticky is that I also pushed them to launchpad.
I made a bzr revert but, if I go to that dirty revision, I can still see those files. Is it possible to completely return to a previous revision, so that those files completely disappear?
Or as an alternative, if I delete the trunk branch of a launchpad project, will I be able to create a new trunk?
So according to TridenT's and jelmer's recommendations the solution is:
1.) `bzr uncommit -r X` Where X is the revision I want to return to
2.) `bzr commit` This created the local revision X+1
3.) `bzr push --overwrite -r X+1` This pushed the stuff to launchpad,
and all those sticky files are gone.
Thank you guys.
If you delete the trunk branch of a launchpad you will be able to create a new trunk.
You can also completely go back to the previous revision by using "bzr push --overwrite -rREVNO" where REVNO is the revision you want to go back to.
You can do a uncommit.
For the user, this will remove it from the branch.
In the bzr repo, it will in fact unlink the revision from the main line.
Related
I have a git project that I'm about to push to SourceForge. The origin for my local repo is a shared file system repo that gives me a backup facility.
When I eventually add SF as another remote I just want to push the latest (= versioned) commit to it as the starting base of my code on that repo, and not include all the previous commits that contain possibly rubbish/sensitive/embarrassing code.
My question is similar to this one, except that question was about just leaving out some of the history - I want to leave out all of the history and have the latest commit to become the starting point of the project code on SF. Importantly, having done this, I want "push to upstream" to continue to work even though origin and SF will be different.
Is this possible? Incidentally I'm doing this through Eclipse ie. eGit.
Update
My original question should have been clearer, although the answers so far have helped clarify exactly what I'm trying to achieve.
I want just consolidated commits pushed to SF, representing the published versions.
This is what I want to do:
[master] A--B--C--D--E--F--G--H--I... --> push to origin (private)
\ \
[public] V1----------V2... --> push to public remote repo
#michas's answer starts me off with V1 on branch public, but I can't figure out how to continue to extend this branch with subsequent version commits. I've experimented with rebase but can't get the result I want.
It sounds like you want to start with a new repo. Why don't you just delete or rename your old repo and create a brand new one. Then copy all of your files in, commit them, and push.
Well, you cannot push the current commit, as this commit contains the whole "rubbish" history.
However you can create a new commit with the same content but without any history.
git checkout --orphan fresh # create a new branch called `fresh` without any history
git commit # add your work as a new commit
git diff fresh master # the both branches should contain the same content (assuming you original branch was called `master`)
git log # verify the current branch does not contain any history
git push sf fresh # push that branch
git push sf fresh:master # (or you might want to call that branch master on sf)
The answer provided by #michas didn't allow me to subsequently maintain the branch with consolidated history. This required the use of git merge --squash. The scheme I eventually came up with was similar to the one described here.
Just tidying up so the question has an upvoted answer.
We had a number of developers working on a large website project using Git. We have a GitHub repository and then we have the website on the server, plus all the developers have their local versions.
When we finally launched the project, I got lazy (hangs head in shame) and started making changes directly to the server, without pushing them back to the Github repo. However, other people made changes to the repo, for reasons I don't quite understand, that were never pushed down to the server and are now either outdated or wrong. We have been doing this for almost seven months.
Now the server and repo are hopelessly out of sync. I would now like to get the most updated version of the site (which is the server) back up to the Git repository so we can begin another round of development. I basically want to start with a fresh copy of what is on the server.
How would you recommend I proceed? That was the first time I had used Git. It didn't seem like such a big deal at the time but now seems like it is harder to start up again than I thought.
I have looked for instructions and don't really see anything that fits. Because I am not super confident in my Git skills, I am afraid to just start trying the few ideas I did find and losing what I have on the server.
(I know I could restore from a backup if I really messed it up but would prefer not to do that as it would take the site down.)
Can I uninstall git and start again with a fresh repo? Or is there a safe way to push the current version up to the repo?
Thanks for your help.
UPDATE: I found this answer elsewhere (Replace GitHub repo while preserving issues, wiki, etc) but I am not sure how to do this:
cd into "new" repository
git remote add origin git#github.com:myusername/myrepository (replacing myusername & myrepository accordingly)
git push --force origin master
Possibly delete other remote branches and push new ones.
Not sure what they mean by "new repository"
Make a new branch and push it to GH.
Make a new branch based on the previous
branch.
Switch to the new branch (created on #2).
Delete all the files and folders on this branch repository
except the .git folder and contains
(maintain the README.md,
.gitignore and other files if you want it).
Copy all the files from the server except
.git folder.
Commit.
Switch to local Master (created on #1)
Merge this new branch with the previous one.
Solve conflicts
(I use SmartGITthat have a visual conflict solver and helps me a lot, but you can use gitdiffif you don't want a visual interface)
Commit
Push it to GH.
I hope this helps
I figured this out. What I did was:
Make a new branch on Github to effectively store a backup.
$ git add . to stage all changes
$ git commit -m "Commit message" to commit changes
$ git push --force origin master to force changes from server to remote branch master
Once I did this, there were still hundreds of files I had deleted on the server that were not reflected on the remote github.com repository. I used the following:
$ git rm $(git ls-files --deleted)
See Removing multiple files from a Git repo that have already been deleted from disk
Then repeated git commit and git push. Now my github repo matches my server exactly.
I have not yet deleted the "backup" branch I created on github but I will.
Hope that helps someone.
We've just spent two weeks working down the wrong path on a problem (with all the commits to our SVN repository that go with that). We've now come up with the right solution (which needs our code base to go back to what it was two weeks ago). We should have branched two weeks ago, but that is irrelevant now.
Clearly, I can make a second checkout of the project and then copy that over the current version of the repository and check that in.
Is there a cleaner way to do this without a second checkout?
There are many ways to do what you want. The simplest would be to check out a new copy of the codebase to a dev machine, specifying the revision for the commit made just before you went down the wrong development path. Then, simply check that code back in as the latest revision. Not only do you effectively "revert" the codebase to that revision, if you find out that some element of your wrong solution was useful after all, you still have easy access to those elements.
Also, as was said, you can branch the codebase at any time, at any revision. Simply cut a branch of the revision before you began your work, and continue along your new dev path. Keep in mind that merging this branch back into the trunk could be problematic; you'd want the end result of development in the branch to replace the codebase of the trunk wholesale. That's possible but it can get messy.
There are a few ways of handling this:
Revert your changes:
$ svn merge -r$rev2:$rev1 .
This is assuming that $rev2 > $rev1. This will back out the changes between these two revisions. If you're backing out a single revision, you can use this:
$ svn merge -c -$rev .
That is, the revision should be a negative number. This will back out just that one revision.
Recreate the Branch
If this work was not done on trunk, but on a branch, and you pretty much want to toss out that branch, you can simply recreate the branch, and even delete the old bad one. Branches (and tags) can be created from any point in time:
$ svn cp -r$rev $REPO/branches/$bad_branch/$proj $REPO/branches/$new_branch
$ svn delete $REPO/branches/$bad_branch
The solution provided by Mike works for me.
In a separate branch
$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
(this undoes the change between 302 and 303).
Then you can commit the changes in your branch, test and then merge back to the trunk as normal.
I created a stable but I accidentally changed a file while working with stable branch. I committed and now my default (which is development) doesn't have it. I tried hg pull -r <changset> where changeset is the latest commit.
What should I do?
hg merge stable
This will merge the two together.
Visit https://www.mercurial-scm.org/guide and go to Merge the named branch.
You don't have to close it.
We just moved over to Git from SVN. In trying to clean up some unused files. I saved before deleting one folder that I thought we weren't using. I did not push this to the origin. I realized we are using one of the files in the folder after all, and would like to revert to my last commit. This is on my own branch from the master. I can't find a way to do that in Xcode. Am I missing something? Thanks.
You can see here for rsanchezsaez answer: Xcode 4 git integration
Xcode 4 won't let you to checkout older commits within the user interface, unless you created a new branch for that commit. Nevertheless, you can do it from the command line. For that, use the following command from your project folder
$ git log --format=oneline
to get the hash code of the commit you want to go to, and then use:
$ git checkout desired-hash-code
to checkout that particular version. Once there, you can make tests, changes, and possibly create a new branch. If you do a commit without creating a new branch, you will lose the newer commits in your current branch. If you want to go back to the newest commit after having performed some tests on your older version use:
$ git checkout master
note again that this won't work if you do a new commit from your old code version without creating a new branch, because newer commits in the current branch get dereferenced.
Also, please consider searching SO before asking. Many questions had already been asked and answered.
From the command line, run a program called gitk - this will allow you to visualize the commits you currently have. Find the ID of the commit you want (e.g. the previous commit) and do the following on your branch:
git tag JustInCase
git reset --hard <commit ID>
Refresh gitk, and if you're happy with the results then delete the tag using:
git tag -d JustInCase
If you're not happy with it, just do:
git reset --hard JustInCase
git tag -d JustInCase
To visualize this for you:
1) Start
2) After tagging and resetting your branch to the previous commit.
3) After deleting the tag and doing Reload in gitk.