I have a mercurial repository in which I had created a branch 7-8 months back. And now this branch is the one in which I do most of the development and I don't have anything fruitful in default branch and other branches that I have.
I want to create a new repository that represent only this branch. i.e. I want to move this branch to a new repository with history.
I tried to use HG convert tool with following syntax:
hg convert --filemap ~filemap.txt --branchmap branchmap.txt --source-type hg --dest-type hg "E:\MyStuff\Dev\MyOldRepo" "E:\NewRepo"
File map I have defined all my file that I want to include. In branchmap file i had defined
MyOldNamedBranch default
Convert tool do rename MyOldNamedBranch to default but it also brings the changesets from other branch that I don't need.
I also tried to set the following in setting file but no results:
[convert]
hg.usebranchnames=0
hg.startrev=5262
Please suggest how I can move a branch to new repository with history and leaving other branches behind.
I have set the start revision number in command only and it worked.
hg convert --config convert.hg.startrev=5262 --branchmap branchmap.txt "E:\MyStuff\Dev\MyOldRepo" "E:\NewRepo"
And it worked like a charm.
Try this:
Clone only the branch you need:
hg clone E:\MyStuff\Dev\MyOldRepo -b MyOldNamedBranch .\NewRepo
Then inside the NewRepo, convert all the changesets to the draft phase:
hg phase -r 0 -d -f
Then update to the patent of MyOldBranch (I assume, that the parent is in the default branch)
hg update -r "parents(min(branch(MyOldBranch)))"
Then rebase MyOldBranch on the exactly the same changeset.
hg rebase -s "min(branch(MyOldBranch))" -d .
Do exactly the same with the rest of the branches.
To be honest I'm not sure if this is the best method but it worked for me.
Related
Is there any way of simulating a git merge between two branches, the current working branch and the master, but without making any changes?
I often have conflicts when I have to make a git merge. Is there any way of simulating the merge first?
You can use git merge --no-commit to prevent the merge from actually being committed, and if you don't like how the merge works out, just reset to the original head.
If you definitely don't want to finalize the merge, even if it's a fast-forward (and thus has no conflicts, by definition), you could add --no-ff as well.
I don't think there is a way of simulating what will happen until you try the merge. However, if you make sure that the output of git status is empty before you do the merge, it is quite safe to just go ahead and try it. If you get conflicts, you can immediately get back to the state you were at before with:
git reset --merge
Since git 1.7.4, you can also abort the merge by doing:
git merge --abort
(As the commit message that added that option explains, this was added for consistency with git rebase --abort and so on.)
If I want to compare changes on a topic branch to master, I find it easiest and safest to do the following:
git checkout master
git checkout -b trial_merge
git merge topic_branch
After completing the merge, it is easy to see the consolidated change from master
git diff master
When done, simply delete the trial_merge branch
git checkout master
git branch -D trial_merge
This way, the master branch never changes.
Here is the solution that I have found: git merge-tree does merging "in memory" and prints the diff without touching your working directory. You can even test a branch without checking it out.
Get the merge diff
First, do this to make sure your repository knows about all the remote branches:
$ git fetch --all
Now use this bash snippet to see how branch $branch would merge into $master:
$ branch='feature'
$ git merge-tree $(git merge-base $branch master) master $branch
No changes are made to your workdir or index. It's a dry-run merge.
Pick information from the output
The output is a diff.
In case the branch has been merged, it will be empty.
To find whether there are conflicts, grep it for <<<:
$ git merge-tree $(git merge-base $branch master) master $branch | fgrep '<<<'
To extract conflict diffs, use sed to extract lines between <<< and >>>:
$ git merge-tree $(git merge-base $branch master) master $branch | \
sed -ne '/^\+<<</,/^\+>>>/ p'
Features
The diff will be empty if a branch is already merged
Use grep/sed to extract conflicts information
Use origin/feature to test branches you've never worked with
Can be used to see how 2 branches have diverged
Add it to your favorites
Get the diff of the merge:
git config --global alias.mergediff '!f(){ branch="$1" ; into="$2" ; git merge-tree $(git merge-base "$branch" "$into") "$into" "$branch" ; };f '
Usage:
$ git mergediff <feature-branch> <merge-into>
$ git mergediff feature master
Get merge conflicts:
git config --global alias.mergetest '!f(){ git mergediff $# | sed -ne "/^+<<</,/^+>>>/ p" ; };f '
Usage:
$ git mergetest <feature-branch> <merge-into>
$ git mergetest feature master
Why not just create a throwaway branch (git checkout -b), and do a test merge there?
I use :
git merge --ff-only
according to documentation:
Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward.
It's not really a simulation because there will be a fast-forward merge in case of no conflicts between the two branches. But in case of conflicts, you will be informed and nothing will happens.
I've been able to use git merge --abort, recently. However, this can only be used if there is a merge conflict. If you are sure that you will not want to commit, then use the other mentioned methods above.
I don't know exactly if it is your case, but your question remember me that sometimes I start a feature, I commit over the days and I merge the develop on it many times.
On this point I lose the control over the exact files I changed and I will only know it when my feature were closed and my code go to develop.
In this case, a good way to know what modifications you did (not other from the merges) is using Sourcetree.
You must click with the right button on the base branch and select Diff Against Current:
Then sourcetree will show you all the modifications that will be merged if you merge your branch into base branch.
Of course, it will not show you the conflicts, but it is a useful tool in merges.
I've created a changeset which contains a number of individual changes. I've realized that one of those changes might not have been a good idea, and I'd like to update my working directory to include only part of that changeset to work on, without throwing out the changeset itself.
In git terms, I want to do something similar to git checkout -p HEAD~, or the similar
git checkout -b newbranch
git reset HEAD~
git add -p
git checkout -- .
How can I do this in Mercurial?
Read carefully hg help revert, pay special attention to -r option and NAME (ordinary list of fileset).
In your case (single changeset, part of which you want to eliminate from Working Dir), you have to:
hg up to the this changeset
hg revert -r "p1(.)" set:SOME-FILESET or, instead of fileset ("set:PATTERN" part), just "... FILE FILE2 FILE3 FILEN"
As result, you'll get in one readable command modified Working Directory with only needed part of changes in it
what does it mean that I see (feature/StoreTextVariable_134) (I assume branch I created earlier in and switched to in VS, and I deleted the local code earlier)?
how can I get rid of it?
I'm a GitBash newbie.
what does it mean that I see (feature/StoreTextVariable_134)
feature/StoreTextVariable_134 is the branch of git that you are currently working on.
Type git branch to check how many branches in your source code.
how can I get rid of it?
Use git checkout to move to the branch you need to work with.
output
Note: If there is a change in source code on the current branch then you need to commit before switching branches.
Please refer more detail here:
Git document
Thanks #Tai I had to use -f with my checkout so that I could discard pending changes I didn't need
git checkout -f branchName
then to delete it I used
git branch -d -f branchName
now I am back on my default branch
I have an old mercurial repository for a project that has the changes before a certain date, and I have another repository for the same project with all the changes after that date.
I want to merge these two repositories so the history reflects that the first commit in the latter repository is the child of the last commit in the former repository.
Is this possible? Or do I just have to merge both heads?
Reading here:
http://blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control/
and here:
https://www.mercurial-scm.org/wiki/RebaseExtension
I looks like what I am wanting to accomplish can be done with a rebase, with some caveats.
I pull the changes from the newer repo into the older repo. This results in two heads since both repos only have the 'default' branch. In the older repo folder, I ran:
hg pull -f ../newer-repo
Then I have to use hg phases to make the pulled changes malleable. Normally, this is a bad idea, but since I know I am the only developer on this project, I can do this safely.
hg phase -f -d -r 15 16 ...
Finally, I can now rebase because the history pulled in from the newer repo begins with the same state as the last changelist in the old repo.
hg rebase -s 15 -d 14
I have a single history and no conflicts.
This probably wont work for everyone, but in this narrow circumstance, this was exactly what was needed.
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.