I have a branch named A. I create another branch from A named as B. I work on the new branch B and push it. Later on I work on branch A and push it. Now, I switch back to branch B but I want it to update with the latest changes of branch A.
so should I merge from branch A to branch B, or branch B to branch A
In a normal case, the result of the merge is usually unique, whether you go to one direction or the other. The branch destination, however, depends only on your interpretation of the branches.
For example, you should merge the development branches in the stable branch only when they are deemed ready, but the stable can go in development more often.
Related
How do I unmerge/remove a previously added branch from a base branch without deleting the merged branch?
Here is the scenario:
Long back I have merged a branch (x) to a base branch (b), since then I have many branches (y, z, ...) to b and have several commits and pushes. Now I need to remove the changes of x from b without deleting b. So that later if required I can merge that branch again and the changes of x are there in b after merge.
Is it possible or do I need to remove my changes in some other branch (o), which will override the changes of x in b.
On my local repository, I created a branch A from branch B. I did some work on branch A, and pushed A to github.
Then I created a pull request on github, in order to merge branch A into branch B, I heard that it is said to be "branch A is pulled from branch B". Is it correct?
Doesn't a pull request mean merging branch A into branch B?
What does "pulling" branch A from branch B mean?
It seems to me that the two meanings of a pull request are contrary to each other.
If you merge A into B it will be:
Branch A is pulled into B.
or
Branch B is pulled from A.
It refers to the branch you're currently at. If you're in branch B and pull from A, that pull will first fetch A and then merge A.
Pull and Merge are two different process.
"branch A pull from branch B" means you make a editable copy, call it A, from B (If A originally not exist).
"Merge A into B" means you are applying all the changes you made in A back into B
the reason people saying that "branch A is pulled from branch B" is because if A is not pull from B, it can not be merged back to B
There are two different uses of 'pull' in git terminology and, while not contradictory, they can be confusing at first.
1. Pull:
From the command-line command git pull (also known as a combination of fetch and merge). Essentially just gets the remote code (or 'pulls' it to your computer) and merges it into your local code. Read more here.
2. Pull request:
When you want to merge your changes into the repo. Generally opens a discussion and review of your changes before the pull request (or 'PR') is accepted. Read more here.
As an aside, there is also a 'push' command, which may make things clearer (and reiterate the direction pushing and pulling to and from local and remote repos). git push 'pushes' your commits from local to remote (i.e. the opposite of #1, git pull). Read more here.
Let's consider following two Mercurial scenarios:
Scenario A:
I have linear history from rev 1 to rev 5, I create branch foobar and commit revisions 5-11 to it. Then I switch to master and commit rev 12 to master. I have two branches (master and foobar), with one head each. Nice.
Scenario B:
I have a linear history from revision 1 to rev 10 (only one branch - master). I'd like to put revisions 6-10 to a new branch and continue my master from 5 onward, effectively putting myself into scenario A. I see that mercurial does not support retroactive naming of branches, so there's no way for me to transition to scenario A, but I'm thinking about hack like this one:
I create a new branch (and name it foobar), and commit rev 11 to it
I switch to master and do hg update -5, and then commit rev 12 to master
Do I now have two branches with one head each? If I understand correctly, the only difference between scenario A and scenario B is that in scenario B revs 5-10 are not labeled with "branch foobar", which in practice doesn't mean much, and all future behavior for scenario A and scenario B is equal. Am I right?
You are correct. When you do a hg update the earlier revision you will see the files as they were at that point and be able to isolate the differences from the revisions that you wanted on a branch.
I have a following question. Suppose I have a bunch of repositories hosted that form an hierarchy, e.g.: A -> B -> C (means A is the central repository and all the rest are it's descendants).
Now suppose I work with the clone of C. Suppose I want to get the changes not just from C, but from the central repository, so I do the following commands:
hg pull [Address of A]
hg up
That seems perfectly legal, but what happens then I commit my changes and push them to C? Not only my local modifications will be pushed, but also the modifications of central repository (if there are any). What will happen if someone will try to pull the changes from A to C? Will there be a conflict or it will merge successfully the changes A -> local -> C with changes A -> C. Will Mercurial recognize it as the same changeset or not?
The identical situation takes place if I decide that my code is stable enough and can be placed in central repository:
hg commit -u spirit -m "A local modification that is stable"
hg push [Address of A]
What will happen if I make a pull from A to C and then pull from C to my local repo again, will it recognize these changeset as originating from my local repo, or will it report a conflict and suggest a merge?
And what is the best practice in that case anyway? Performing just subsequent pulls and pushes (i.e. A<->B, B<->C, C<->local)? But the problem is that I have just access to my local repository that is clone of C. How can I make a pull from B to C if I would want to on my local machine? How does Mercurial handle
What will happen if someone will try to pull the changes from A to C? Will there be a conflict or it will merge successfully the changes A -> local -> C with changes A -> C. Will Mercurial recognize it as the same changeset or not?
The changesets that already exist in C will be seen to already exist because their IDs will already be present. This is why changes are immutable. If you could modify a changeset it's ID would change (The ID is a hash of the changeset contents). Mercurial then (correctly) sees it as a different changeset. By keeping the changesets immutable we can be sure that their hash will be the same whichever repo they come from.
pull = copy changesets from over there that have IDs I haven't seen
push = copy changesets to over there that have IDs they haven't seen
Will there be a conflict
No
or it will merge successfully the changes A -> local -> C with changes A -> C.
No merge takes place because they are the same changes. It just sees that it already has them.
Merges don't happen unless you want to combine the changes from two parallel sets of changes, and not unless you explicitly ask for it.
As long as the changeset are identical, i.e. they have the same id hash. Mercurial considers them to be the same.
When you modify changesets with rebase or mq commands, the id hashs change and mercurial might place two very similar changesets into a repository.
In CVS I have a branch (b) off another branch (a) which is off the trunk/head.
Some bug fixes were made in branch (a) that I'd like to go ahead and use in branch (b). How can I pull those fixes into my branch in Eclipse?
head
|
v
a (with bug fixes)
|
v
b (needs bug fixes)
Ideally what you need is to have two tags on a for every feature you want to merge, and then merge the difference between those two tags into b. However, you would also need to remember which ones you have already merged, because CVS doesn't remember that.
When I was working in a company that used CVS and branches, our policy was that bugfixes from branches (a in this case) that ought to be used by other branches need to get merged into the trunk first, and all the other branches merge them from there.
However, it was still very painful if you wanted to cherry-pick individual bugfixes. Essentially, you'd have to remember every fix you've merged (by two tags, marking the beginning and the end of the changes making up that fix).
Generally, in CVS it's much better to remember (in a tag) up to which revision you have merged, and merge everything from there to the head (and then move the tag to the head). In CVS, cherry-picking is painful and requires you to store the merge history somewhere.