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.
Related
So I started using github today.
Basically, there are two of us (programmers) who will work on a single project with a PIC microcontroller. I have experimented a bit and read a couple of stuff and terms such as branches, commit, master, etc..
So let's say I just have one main.c file containing 4 lines.
This one is our master file. There are two of us developing at the same time. Now we make two branches out of this master (so basically a snapshot of this current code). The two branches are "branch1" and "branch2", with me making changes using branch1 and my partner using branch2.
I inserted a line "dummy = 0" between line2 and line3 while my partner insert "dummy = 0" between line3 and line4. So at the end of the day, I will commit my changes to branch1, pull a request to merge my changes to master.
Now, how does my partner do to make his changes to the new master file (after I committed mine)? Note that we started off from the same master file.
Thanks
What we did so far: We haven't tried making edits at the same time yet. What we did for now was that I asked him to make edits on branch2, then try to pull a request so that I can approve it so that his edits from branch 2 carries out to the master. My problem lies in the fact that we would most likely start from the same master code each day and so every change being made each hour would not carry on to the other one's copy
Git is a versioning system working on incremental differences.
In your scenario, you have 3 branches: master, branch1, branch2. You are both working on the same file in the two dev branches (not master).
Once you pushed your edits with a commit on branch1, your partner won't see anything in branch2: they are divergent paths.
What your partner has to do, is to merge your latest commit into branch2. In this way, the two divergent paths have met, and became one again. If you'll continue on branch1, rinse and repeat the process.
Since you stated that you both added lines in the same file, expect conflicts: "merging" means start from the file as it was back then (at the beginning of branch2), then replay all edits that were done in each commit, in that order. When you'll have to put together the edits of both branches, probably this will conflict. Say for instance that you added dummy = 0 on line 4. Your partner did it as well, but wrote dummy = 1 on line 4. Git doesn't decide for you, you'll have to resolve the conflict and decide which one to keep.
Note that I haven't mentioned master. I'll refer you to gitflow for that, is a little bit too broad of an argument for a single question.
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?
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.
My project uses hgext.notify. Currently incoming.notify = separate messages on every changeset. Considering changegroup notify, but even that contains info about every changeset, just all in one big email.
Here's the problem:
My work style is "check in early and often". I make many small checkins, usually on branches. Task branches. Eventually integrated.
My teammates do not like seeing messages for all of my checkins on my task branches.
We are considering using a history editing extension like collapse or histedit to reduce the verbosity - but I dislike losing history. I just want not to bother them with every individual changeset.
Q: is there a way, some configuration for an existing hook, or some alternate hg extension, that can be set up to do notifies as folllws;
a single message per changegroup (that's okay)
a single user provided message per changegroup - not just concatenation of all the branch changeset messages
filter out only the changest messages for, say, the trunk (the default branch in hg parlance). I.e. leave the branch changeset messages in, but don't send email.
(Note: my pushes typically involve several changesets on a branch, and then a merge onto default. So it is not enough to just filter the entire changegroup in or out according to what branches are affected.)
diffstats not between the tip and every changest on the branch, but just between "important" changesets on the trunk (default branch) - which may be evety changest on the trunk.
I'm afraid no such extension exists. The notify extension is just a basic way to send off emails with a little room for customization.
It sounds like you have a particular idea about what you want. I suggest you see if you can formulate it as a revision set and then simply use hg log in a changegroup hook. Pipe the output to mail and you've got yourself a very simple notify extension that you can customize to your hearts content!
What I'm saying is that the notify extension is not that complex and in many cases it can be replaced by a suitable invocation of hg log. You can even use a custom template for hg log if you want to change the output more than what hg log -v or hg log --patch does.
The tricky part (and the part that's not entirely clear from your question) is to filter out exactly the right changesets. You mention "important" changesets in point 4 above, but I'm not entirely sure what makes a changeset "important". If it is important when it's a merge from a feature branch into default, then something like this might be a start:
hg log -r "$HG_NODE:tip and children(not branch(default)) and branch(default)"
By taking the child changesets of the non-default changesets and intersecting with changesets on the default, we get exactly the merge points where feature branches were integrated.
I'm sorry the answer is so generic, but I think you're best off with writing a small custom shell script for what you want.
Do you know any tool that support the followings:
eclipse integration (not mandatory)
merge tracking
interactive merge
merging with selecting changesets, but commit them one-by-one to preserve commit comments
So the flow I expect:
picking the source to merge to workspace
choosing revisions to merge
the program would do the merge for the first revision, would pop up conflict resolving if any, and if no conflict it would commit with the original commit comment + merging info with appropiate svn properties
go to next revision.
Do you know such tool?
No, I doubt any tool does this exactly as you describe - why would they when you can a) replicate the functionality by merging 1 revision at a time anyway, b) prefer to make the commit a manual process so the operator can check the merged results. Having merges commit automatically is just slightly optimistic.
You could write such a tool with script - for each revision, merge, fetch original log comment, commit.
Note you don't need to worry about properties as they are merged automatically as part of the merge process.