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.
Related
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.
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.
I branched from default a few months ago to work on some changes to a project. However, now I want to make the branch I was working on the default branch. I want don't want to "merge" any changes from the new branch into default, I just want to override everything and replace default with the branch. Am I even going about this the right way? Thanks for the help!
You can specify a merge tool that does this.
First update to the default branch, then issue:
hg merge OTHERBRANCHNAME --tool internal:other
As always you should experiment in a clone so that you can restart if necessary.
I would like to do some experimental work in a hg project. So I would like to create branch, commit to it. And if the experiment works, I can merge it back to main branch.
In git, I can do
$ git branch experimental
$ git checkout experimental
(edit file)
$ git commit -a
$ git checkout master
I've read A Guide to Branching in Mercurial. It said hg branch feature. But what is next?
I don't follow.
$ hg branch experimental
(edit file)
$ hg commit
$ hg update default
First note that git branch is different from hg branch. Branches created with hg branch are permanent and live in a global name space, whereas branches made with git branch are transient. The nearest equivalent of git branch is hg bookmark: bookmarks can be renamed and deleted and behave more like Git-branches.
I've recently written a guide for Mercurial bookmarks. Compare this with the named branch guide. Both guides contain worked examples of how to use (named) branches in Mercurial for keeping track of the development. It shows how to merge branches and how to close them or delete the bookmark when you are done.
If it's not a big feature (i.e. the branch doesn't have to have a name), it's quite simple.
Let's say your repository is at changeset X. You work on the feature as much as you like, commit, commit, commit and if you're happy with the result, continue as if you knew it would work all along. ;) If you aren't happy, do a hg update X and continue development from there. All the work you did on your experiment will become an anonymous branch.
Strangely enough, it appears that Git doesn't provide such a way to work with anonymous branches which is what might be confusing you.
Specifically, I'm using bzr, but tips for any VCS are welcome.
I think there are three options.
Use shelving
bzr shelve --all
bzr unshelve
Create a separate branch with the
latest
Create a patch of you
changes and revert the changes.
Apply patch when you need your
changes back.
Using Git:
git checkout HEAD^ # get the previous version, changing files on disk to match
make # run your project (or whatever command you use)
git checkout master # return to the "master" branch
The above applies if you've already committed whatever current changes you're working on, and want to go back to the previous commit. If you have changes that have not been committed yet, then use the stash:
git stash # save the uncommitted changes away
make # ...
git stash pop # restore your uncommitted changes
You can make and commit other changes in between the stash and the pop; this is Git's solution to the "boss interrupts with an immediate bug fix request" problem.