I am stuck in a scenario in which I have created a branch on Mercurial Workbench from a wrong parent branch. In other words I had to create a feature branch from parent : xxx and I have created it from parent : yyy.
Please note that I have also committed the changes, Is there any way I can either redirect my feature branch to xxx or I can delete the branch and re-create it with the same name (please note that having the same name is important) but this time I can create it from xxx.
I have exported the patches of my commits so after creating a branch even if my commits are lost I can import the patches again.
If you needed to change the branch name you would want hg graft (see Graft vs. Transplant). But since you don't want to change the name, you only want to redo the base of the commits, you want hg rebase.
See Hg: How to do a rebase like git's rebase and also In Mercurial what's the difference between hg graft and hg rebase. Note that rebase is an extension, but is a bundled one: you merely need to enable it.
Related
Is there any way to replace merge with rebase at GitHub PRs? I looked through protected branches settings but didn't find such option.
GitHub now (Feb. 2022) supports this:
More ways to keep your pull request branch up-to-date
The Update branch button on the pull request page lets you update your pull request's branch with the latest changes from the base branch.
This is useful for verifying your changes are compatible with the current version of the base branch before you merge.
Update your pull request branch by rebasing:
When your pull request's branch is out of date with the base branch, you now have the option to update it by rebasing on the latest version of the base branch.
Rebasing applies the changes from your branch onto the latest version of the base branch, resulting in a branch with a linear history since no merge commit is created.
To update by rebasing, click the drop down menu next to the Update Branch button, click Update with rebase, and then click Rebase branch.
Previously, Update branch performed a traditional merge that always resulted in a merge commit in your pull request branch. This option is still available, but now you have the choice.
Note: Because rebasing rewrites the history of the branch, if you are working with the branch locally, you will need to fetch it and do a hard reset to ensure your local branch matches the branch on GitHub.com.
Learn more about keeping your pull request in sync with the base branch.
I doubt github supports this, as you should never rebase a public branch. From the official git docs:
Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.
The easiest solution would be to simply use a merge. If you don't like that for any reason, you could create a new branch from main, apply the desired changes (e.g. by using git cherry-pick, or git diff in conjunction with patch), and then delete the old branch and create a new PR. If you really want to use rebase, you can do so locally and force-push the branch, but again, that's a really bad idea as it falsifies history and breaks the branch for everybody else.
I cloned a Mercurial repo and made some changes in the checked out code. I then grabbed those changes (7 files) and committed them with hg commit but without having created a bookmark first.
This is the output of my hg summary command:
parent: 8172:b39efc1322fe tip
Made some changes in my feature
branch: default
commit: 7 modified
update: 2 new changesets, 3 branch heads (merge)
phases: 3 draft
These changes won't be ready to be pushed for at least another week, so I want to switch to a new bookmark and work on other parts of the code.
The problem is that I realized that I had made a commit without being in a bookmark, so I'm afraid that after switching to a new bookmark my committed changes could be lost.
Is there an easy way to move these committed changes into a new bookmark?
There is no need to be afraid at all: mercurial won't forget anything you committed unless you explicitly do both: enable history editing extensions and willingly use them in a way that you actually remove one or more changesets.
Mercurial is not git and mercurial does never forget or garbage-collect a changeset when it is not currently checked out and has no name (bookmark) attached to it.
You can show you all your heads using hg heads. And you can always create new bookmarks, attached to an arbitrary changeset by hg bookmark --rev XXX MyBookmark where XXX is the changesetID to which you want to attach the bookmark.
I'm afraid that after switching to a new bookmark my committed changes could be lost.
How can you imagine this? OMFG, you committed your changes to repository (your clone), you have this changeset (8172:b39efc1322fe) in it. When|if you'll svn up to another node, you'll just change parent of your Working Directory, on pull you'll get "2 new changeset" and, as result "3 branch heads" - 2 new changesets + your commit 8172, and this b39efc1322fe will be always one of heads, even you'll up and work in another.
If you are afraid to forget it (how??? really), you can post-fact bookmark this (committed) changeset with hg bookmark -r b39efc1322fe $WIP && hg commit -m "Bookmarked my work" in order to hg up $WIP when it will be time to continue this chunk of changes
The situation:
Several branches I constantly have to merge between them. Each branch has a special file that identifies the branch (with certain settings for commit mails, plugin options and more, doesn't matter here).
The problem:
Whenever I merge one branch to the other and this special file has been changed it will obviously overwrite the merge target file. But I don't want this to happen. Those files must be version controlled in their branches as they are an essential part of it, but they should not be merged at all as they contain branch specific information.
The question:
Is it possible (and how) to exclude a specific file from a merge? I'd like a solution that doesn't requier me to specify this on each merge as a paramter, but if there's nothing else then I bite the bullet.
The only way to exclude a file from a merge is to revert it right after the merge, before you commit, for example:
cd /path/to/repo/trunk
bzr merge ../branchA
bzr revert file/to/exclude
bzr commit -m 'merged from branchA'
Later, when you merge again from branchA, the bzr revert step in the middle is only necessary if the file changed in branchA since the last merge. So if the file doesn't change very often, then "biting the bullet" might not be all that bad.
Me and my friend need to develop a project parallely. how to do this?
I created two branch worked on each leaf. Tried to merge the leaves but getting conflict error for edited file. What is the way to merge them?
I would like to know if it possible to have 2 leaves in a single branch? If so then how to create a new leaf in addition to the default leaf.
Each branch has one leaf at any time. These represent the most recent state of the repository from the perspective of each branch. As your post mentions, branches are used to afford parallel developments within the repository. They are also created automatically (called a "fork" in such a case) to prevent two commits to same branch when each commit has the same immediate ancestor... allowing this would be just like having multiple leaves on the same branch.
To create a new branch of development, one opens a fossil repo and executes a command like:
fossil branch new some_feature trunk
Complete example
For the sake of example, I quickly created a new repository and added a single file to the trunk (the only branch initially), file.txt. The initial contents of my example file are:
here
is
a
file
After committing the added file with the comment, "create baseline", I created a development branch for a new feature called "some_feature" based on the current state (aka the leaf) of the trunk branch...
fossil branch new some_feature trunk
Now there are two branches, trunk and some_feature. Creating the branch does not change my working branch, so I am still in trunk. Then I edited the baseline file to:
here
is
a
file
folder
...adding "folder" to the end. Then I committed the change to trunk with the comment, "modification on first branch... trunk. Then I switched development to the some_feature branch...
fossil co some_feature
From this second branch, I also edited the last line of the baseline file:
here
is
a
file
reader
...adding "reader" to the end. Then I committed the change to some_feature with the comment, "modification on second branch... some_feature".
To merge development, you chose the branch you want to merge changes into. In this case, I will merge the feature branch changes into the trunk. To do this you must first checkout the destination branch for the merge... in my case, trunk.
fossil co trunk
Then, I merge in the change from the specific commit of the other branch. In my case, I'll use the leaf of that branch:
fossil merge some_feature
MERGE file.txt
***** 1 merge conflicts in file.txt
WARNING: 1 merge conflicts
"fossil undo" is available to undo changes to the working checkout.
This leaves me with four files now in my working directory instead of one. No new commit/checkin has actually made it back to the repository proper. The four files are: file.txt, file.txt-baseline, file.txt-merge, and file.txt-original. "file.txt-baseline" is the file as it existed in the most recent common ancestor of the merging branches. "file.txt-original" is the file as it existed in the target brach, in my case, trunk, just before the merge. "file.txt-merge" is the file as it existed in the branch you were merging from, in my case, some_feature. Finally, "file.txt" contains the contents of the baseline file with conflicting changes from the original and merge files annotated so you can decide how to deal with the differing contents.
In my case the generated conflicts file, "file.txt" looked like this:
here
is
a
file
<<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<
folder
======= COMMON ANCESTOR content follows ============================
======= MERGED IN content follows ==================================
reader
>>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Until the merge conflict annotations are removed from the file, fossil will not let you commit (or it will at least warn against it). Otherwise, you would make a commit with message, such as, "merged some_feature into trunk".
For reference, here is the event history diagram as provided by fossil for this example:
I'm just starting out with bazaar, and I've found that the checkout feature is the most useful for the way I work - namely I can c/o from a "master copy", do some development and then commit my changes in the new directory. This then updates the "master copy".
But what if I'm working on (eg) two projects, changing different portions of code? Say:
~/master - master copy
bzr co master ./gui
bzr co master ./engine
So I'm doing gui-related stuff in the ./gui directory and under-the-hood stuff in ./engine. How should I commit my changes? If I commit gui first, then engine, I guess any conflicts will be flagged in engine?
Is there a way to merge gui and engine, and then do just one commit to the master copy?
To make things a little more complicated, how about if I do this:
bzr branch gui ./mouse
Now I perhaps I've been working on mouse, but also on gui. If I want to merge the code from gui AND mouse, and then commit to master, what is the best way to manage this? Or indeed, if I also:
bzr branch gui ./keyboard
If I've changed altered gui, keyboard and mouse, should I hierarchically merge - ie mouse+keyboard, then merge this with gui, then commit gui to master?
I hope it is clear what I'm trying to achieve! Thanks in advance for your time.
If you have two checkouts, any time you commit changes to one, you will first have to pull down any changes from the other one, potentially having to resolve conflicts at each step. This is generally a good idea, since it's easier to resolve conflicts over time and make sure your code doesn't diverge too much.
However, it sounds like you want to have separate developers working on "gui" and "engine", or you just want to save your conflict resolution till development on both branches has completed. In this case, you should probably create them as independent branches with "bzr branch". Each branch can use local commits and not worry about conflicts with each other. Then when it comes time to merge you can do it one of 3 ways, all of which get the same end result:
1. Merge one branch into the other, then push it up to master:
cd gui
bzr merge ../engine
# manually fix any conflicts
bzr commit
bzr push #back up to main
The downside to the above method is that your "gui" branch now has the "engine" changes in it. Which is fine if you're going to throw away both branches once they're pushed back into the mainline. But if you want to keep the branches longer, you can:
2. Merge into the mainline:
cd master
bzr merge ../gui
bzr commit
bzr merge ../engine
# manually fix conflicts
bzr commit
This has the upside that you still have "gui" and "engine" as separate branches, but you've had to commit one to master before you were sure that they would both work together. So you really probably want to:
3. Create a merge branch:
bzr branch ~/master gui-engine-merge
cd gui-engine-merge
bzr merge ../gui
bzr commit
bzr merge ../engine
# manually fix conflicts
bzr commit
bzr push ~/master
# since this branch was only for merging, you don't need it anymore:
cd ..
rm -r gui-engine-merge
Yes, bzr should prevent you from checking in changes from the engine repo if it detects conflicts. Normally, you first do "bzr up" just prior to check-in and then make sure your stuff plays nice with others.
As for the second part of your question, dealing with mouse/keyboard branches, this is how I would normally do it. Simply cd into the gui dir, and then do:
bzr merge ../mouse
After merging the changes, you can then commit from the gui directory and it will send the changeset to the "master" directory.
Note that I'm hardly a bzr expert, but this is the way I've been dealing with SVN repos.