I would like to merge a feature branch with another, and test the code.
Can I do a merge, run code on the branch, then if I am satisfied, Commit ?
Will this have any negative effects ?
No, it will not have any negative side effects - in fact, that's what you're supposed to do.
Related
I'm still very new to Mercurial so please let me know what I'm doing wrong.
We have an hg repo for each of our developers. I'm working on a new feature in branch x. Since then, others have made critical changes to the project, which I have pulled into my repo. However, when I'm working on branch x my working copy still has the old stuff, which causes it to not play well w/ our shared MySQL database.
Q: How do I update my branch to have the other developers new stuff while keeping my own code in the x branch; I'm not ready for them to have it yet and I definitely don't want to merge x into default... I'm not sure what to do here...
Or am I going about this the entirely wrong way? If so, what should I be doing instead?
[edit]
Also, I'm using TortoiseHG, so if you have any instructions specific for that it would be appreciated.
[/edit]
You are doing everything right. In order to "keep up" with the work of the other developers, you have to merge the default branch into your x branch. Not the other way around.
When you are in your x branch, it is as easy as doing hg merge default.
Edit : I deleted my statement about hg merge being equivalent to hg merge default, which is false. I misread the documentation.
Is it
pull
update
merge
commit
push
? Or can you do the commit first?
I don't like the idea of pulling and merging without having a version of my local code backed up somewhere in case the merge explodes, but presumably you have to do the merge before you can do a push, because you can't have conflicts in the central repo. Not quite understanding this whole process yet; used to my nice simple SVN.
I recommend to always commit before pulling in changes to your working directory, unless you are 100% sure that your changes and the changes to be merged into your working directory will not conflict.
If you do an updating pull (hg pull; hg update, or shorter hg -u pull) and have any outstanding non-committed changes, any changes coming from outside will be combined with your changes. When conflicts happen, it might be difficult to decide how the merge result should look like, because you can't easily distinguish between your changes and the changes merged in.
When you did commit first, it is much easier to decide how the merge result should look like, because you can always look at both parents of the merge.
So, in effect it is:
hg commit
hg pull -u (if no merge necessary, go to 5)
hg merge
hg commit
hg push
Update: As Martin Geisler has pointed out, it is possible to get at the "original" changed version of a file using:
hg resolve --unmark the-file
hg resolve --tool internal:local the-file
or for all files at the same time:
hg resolve --unmark --all
hg resolve --tool internal:local -all
Still, I find the "commit first" system nicer. At the end, it is personal preference...
I don't know as there's a standard per se, but one of the ideas behind Mercurial is that you can commit as often as you like since it goes to your local repository. So you can commit to your heart's content as much as you like before you pull updates.
I tend not to commit very often, saving up for when I'm preparing to push, but that's me. I can see the utility of committing early and often. I do pull updates frequently as I work to cut down on merge fun.
One other thing I do is to keep a parallel clone of my working repo (cloned from the same repository as my working repo, not cloned from my working repo) so that I can check the original state of a file easily, and if need-be check in an out-of-band emergency fix or what-have-you without complicating my current change set.
Do edits
Commit
Goto 1 until satisfied
Pull
Merge & commit
Push if you want to.
Definitely commit before trying to do something complex like a merge. I don't think mercurial will allow you to merge before committing, but even if it did, what if the merge goes wrong. You have no pre-merge revision to go back to.
Commit early, commit often.
If you don't, you are missing out on a huge benefit of a DVCS.
but presumably you have to do the merge before you can do a push, because you can't have conflicts in the central repo
Wrong statement and poor understanding of distributed workflow and parallel development.
You can merge heads before push, but not have or must. Push can put any data to repo, if it needed and intended to be so
By default, push will not allow creation of new heads at the destination,
since multiple heads would make it unclear which head to use. In this
situation, it is recommended to pull and merge before pushing.
(NB: "recommended to pull and merge before" statement)
You can use commit-pull-merge, stash-pull-unstash-merge, perform fetch with modified WC and merge on the fly, don't merge heads at all or sporadically and push --force with +1 heads - there are not common rule for everybody. And any and every such workflow doesn't produce "conflicts in the central repo", but only different DAG.
Each point of divergence, which appear in case of existing your and other changeset from commmon parent in your (or even central) repo is a point of starting anonymous branches in Hg, which (technically) are absolutely legal, applicable and usual way. How they handled is defined by policy and agreement between developers, PM, QA-team and others
I, personally, prefer finish my task (in one or more amount of commits), after it pull and maybe merge, when it approved by development-policy
I am coming from CVS background.
I try to perform branch by cloning.
The current default tree looks like this from hello project.
I try to clone a project out from 'hello' to 'hello-branch-by-clone'.
I did modification on 'hello-branch-by-clone' and commit.
I did not do any modification on 'hello'.
I perform push from 'hello-branch-by-clone' to 'hello'.
I expect to see a branch but I didn't.
This time, I try another way around.
I did modification on 'hello-branch-by-clone' and commit.
I did modification on 'hello' and commit.
I need to pull from 'hello' to 'hello-branch-by-clone', and merge.
I perform push from 'hello-branch-by-clone' to 'hello'.
This time, then only I can see the branch
By applying cloning technique, is there any way I can have a branch view, without having explicitly modify the default repository (hello)
There's no fork because no two changesets share a parent.
A cloned repository isn't special in any way. It's identical to the original. Commits to it are identical to commits in the original repo. They aren't notionally tagged as being on a branch. A clone is just a nice way of having another work area that you can do some work (including commits) without effecting the original.
A fork occurs when two or more commits have the same parent. Often this happens when using clones, but it may not. If there's only one changeset with the same parent, there is no fork.
After your first sequence you've introduced just one changeset (4) which is which has the old tip (3) as it's parent, so it's still a straight line. Only when you introduce a second changeset parented by (3) will you see a fork.
Now remember, even though you 'push'ed the changeset back, and the original "Hello" repo contains all 4 changesets, it's working directory is still pointing to changeset (3). It will stay that way until you run 'hg update' inside it. This means that if you were to make a commit in "Hello" it will be based upon (3), and then a fork will appear. It doesn't matter when this commit is made.
This is what you did in your second sequence.
Hope that helps.
I've tried to use the term 'fork' in this, because 'branch' has lots of meanings, including the 'hg branch' command which does some slightly different things.
My company is switching to Mercurial, and we're coming from Subversion.
We're noticing that we're having to do a LOT of merging in our workflow. For instance, if I change a file, commit, pull, update, push, and then my co-worker changes a file, commits, pulls, and updates, he gets a "crosses branches" error and has to do an hg merge. We're having to do this pretty much every single time we want to push to our central repository.
Is something wrong with our workflow?? It seems wrong that in our history for a given file there are going to be a ton of history entries that say "Merging with [changeset id]" "Merging with [changset id]."
Is this just the way it is? Or are we doing something wrong?
There's nothing wrong with this. The vast majority of merges should be automatic. You did create two heads when you both made changes stemming from the same revision and going in divergent directions - your changes might or might not conflict.
If you want to eliminate the "merge" changesets (which aren't actually a problem), you can change/pull/rebase/commit/push instead of change/commit/pull/merge/commit. In other words, before committing your changes, rebase them to the new tip.
If the merges are being executed without manual merge resolution, then I would say mercurial and your workflow are behaving as designed.
It is common as you really do need to get your repos in a consistent state. One thing that speeds it up is instead of
hg pull; hg update
use fetch
hg fetch
This will intelligently do a pull and than either an update or a merge. It comes with mercurial so it's basically a matter of editing your .hgrc to add a line like so:
[extensions]
hgext.fetch=
If the merge goes cleanly you won't even notice it happening. That was a big help in my workflow.
Compare to standard push/pull, what is the advantages of using the rebase command in Mercurial?
This post has a nice explanation:
The answer lies in rebasing. Rebasing is a technique made popular by git where you rewrite your not-yet-pushed patches so that they apply against the current remote tip, rather than against the tip of the repository you happened to last pull. The benefit is that your merge history shows useful merges—merges between major branches—rather than simply every single merge you did with the upstream repository.
Normal pull, merge, push sequence will create a number of commits that are not very useful in terms of the history of your repository. Rebasing helps to eliminate these.
If you do a pull-merge-push sequence and get the "merge" wrong you can always "backout" the "merge commit". Thus, you have an easy way of "undo-ing a push". I don't know if there is an equivalent easy way when using rebase.