I found many ways to compare two commits/branches/tags, but I can't find a way to compare all commits in branch.
Suppose we have only branch master with 4 commits
example
We can easily compare all commits except first one in that or
that way
But none of these include changes from 'empty repository' state.
How could I do that?
Related
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.
I would like to support the following situation:
development happens on two branches - they are both a bit like "default" (actual development happens on feature branches, but they are branched of and merged to one of these two branches)
I would like to merge changes from one branch to another in both directions without grafting individual commits
branches have a diff (on big merge of a feature branch) that I would like to always keep and support
I tried to do a dummy merge as described here, first in one direction, then after several successful merges, in another direction (dummy merge of dummy merge). Now I need to do a merge again in another direction, and here another dummy merge (of dummy merge of dummy merge) does not help me any more (and I hoped that one dummy merge would be enough anyway).
Is it possible to do development in this fashion, or is it better to do most of development in one branch? (well, I know it is better for hg, but I have reasons)
Preface
If both branches share the same functionality (unstable common DEVEL), I can't see any reasons in such splitting, except added headache
Face
You can avoid merging unwanted changeset from one branch into another and use ordinary merge if you'll convert this mergeset into MQ-patch ( or maybe shelveset) and always merge from|to (read "Merging patches with new upstream revisions" for merging to branch hint) branch with unapplied patch
Using git, I created a local branch to work in. Then I committed my work progressively. So, I get 3 commit in the same pull request I'd liked to merge them into a single one.
I founded that there is a way to do it if we follow these steps:
git rebase -i HEAD~3
=> All commit in the branch are listed as below
pick mycommit1
pick mycommit2
pick mycommit3
To meld them into the first one, I have to set the commands of mycommit2 and mycommit3 to squash instead of pick
But, in my case, there is lot of commits between my commits in the master branch, thus, I can not do this.
By consequent, I would ask if I can do the merge JUST in my pull request.
Your ideas are welcome.
Thanks
You can use the fixup command while rebasing. This command does the same thing as squash but while keep the message of the first commit. For instance:
pick 123abcd
pick abc1234
pick a1b2c34
You can change this to:
pick 123abcd
f abc1234
f a1b2c34
Now you join these 3 commits into one commit which will get the first message. If you want to edit the message once, you can do it like this:
pick 123abcd
f abc1234
s a1b2c34
This means that these 3 commits will be joined into one commit and you can edit that commit.
Extra Tip: To make it easier to change every pick to a command, you can simply use Vims block select feature to select all 'pick's and change it to the command you want.
I want to pull a set of changesets from a certain branch in a remote repository. One of the changesets is a merge from another branch, which I don't want to pull. However, it will be pulled even if I specify the branch name:
hg pull -r REV -b mybranch REMOTE_REPO
Is there a way to pull this commit as a regular changeset, ignoring its other ancestors?
No, this is impossible. All changesets (whether they are regular or merge changesets) depend on their ancestors and cannot be pulled in isolation. This is a fundamental design decision in Mercurial.
Merging prematurely results in the annoying situation you describe — each branch is no longer clean and cannot be pulled without also pulling in other stuff. The best way to avoid this is to use rebase (if the development is local-only and thus elegible for rebasing) or to simply ask people to stop mixing unrelated things together until you can make a firm decision about what needs to be merged.
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.