On Thu, Nov 10, 2011 at 6:31 PM, Greg Watson
<g.watson@xxxxxxxxxxxx> wrote:
Roland,
What happens if I do something in master and want to back-port it to ptp_5_0? I currently work in both trees and will need to continue doing this.
It would be possible to back-port using cherry-pick. This of course would negate all the advantages listed and would complicate the history. Also in rare cases (conflicting changes to the same file between the initial commit and the cherry-pick) it could cause additional (unnecessary) merge conflicts.
So it would be advisable to try to always do the bug fixes in the ptp_5_0 branch/workspace first and than merge those into the other. Would that usually work for you? If not why not (e.g. do you think you will forget to do it in the right branch first, or do you not want to switch work-spaces as often, or do you not know before hand whether it should also go into ptp_5_0)?
E.g. if one has accidentally committed it into master first one could cherry-pick it into ptp_5_0, than reset master to the previous commit and merge it into master.
Also, please provide an example showing the exact steps I would use to:
1. Add a new file to ptp_5_0 and the steps to merge this into master.
- You would add the file in ptp_5_0 (Team->Add (optional), Team->Commit)
- Than if you use two work-spaces:
You would need to get the updated 5.0 branch into the master workspace. You can either push it to the remote repository (Team->Push to Upstream) and pulling it from the master one(Team->Pull). Or you could directly Fetch it from the other local repository. You need to set this up once (*) This is both faster and if you made a mistake you can still correct it before you push it to the official repository.
- If you use one repository you switch branches (Team->Switch To->master)
-Now you can Merge ( Team->Merge->ptp_5_0)
BTW: Merging into master would not have to be done immediate. It could be done infrequent only when they bugfixes are needed in master.
2. Make a change in ptp_5_0 that produces a merge conflict in master, then the steps to resolve the conflict.
Same as in 1. Then after you did the merge and it told you that you have a conflict:
Team->Merge Tool (opens compare view to manual resolve)
After a file has been resolved: Team->Add to mark it as resolved
Team->Commit (automatically only commits the correct file - not other files not part of the merge)
3. Change two files in ptp_5_0, push the changes, then only apply the change from one file to master.
The two files should be changed in two different commits. If they are not one should go back and fix the commit (Team->Reset->Mixed, 2xTeam->Commit)
This reduces the problem to: Make commits in ptp_5_0 and merge only some of them into master:
Merge all as before
Open History View
Right Click commit which should not be in master->Revert Commit
(*) Setting up a link to the other local repository so that it is possible to directly fetch from it:
Repository View
Remotes
Right Click->Create Remote ("remote" hear mean just any repository which is not the same one - so it applies even though it is on the same machine)
Some name, Configure Fetch
Change
Local File (Select local directory of other Directory)
Advanced->Edit
Add all Branches Spec
Finish
Save and Fetch
Roland
Thanks,
Greg
On Nov 10, 2011, at 5:59 PM, Roland Schulz wrote:
Hi,
I would like to suggest to change how we introduce bug fixes both into the ptp_5_0 branch and the master branch.
Currently the cherry-pick is being used. I suggest, we always add bugfixes to ptp_5_0 first and than use merge to get them into master.
Cherry-pick works by copying a commit from one branch to another. Because the commit is being copied, the history looses the connection between the two commits. E.g. to check whether the other branch contains the commit one has to search for a commit with the same name. The log doesn't visualize it in the graph. Merge works by making all commits of another branch shared ancestors. All commits of that branch become thus part of both branch history and commits are not copied but instead referenced from both branches.
The advantages of merge compared to cherry-pick are:
- The history is clearer. Each logical commit only appears once independent of how many branches contain the commit. The lines show which commits are part of each branch.
- The egit support seems better (maybe because it is the more usual git workflow). Egit has a wizard to resolve merge conflicts but not for cherry-pick
- One cannot forget to copy bugfixes from the release branch to the master branch. Instead by default all changes from the release branch gets merge and one reverts the few commits of the release branch which should not go into the master.
In practice I propose, once, we mark all changes as merged (using "git merge -s ours ptp_5_0"). We would need to mark them as merged so that GIT knows that we don't want to merge changes we have cherry-picked or which comes from the CVS import . From than on we would stop using cherry-pick and use merge (Team->Merge) instead. For the few commits which should go into ptp_5_0 but not into master I suggest to merge as any other and than revert them (Right click in History->Revert Commit). This makes it very clear that this commit wasn't forgotten and is very easy to use. Since only very few commits should fall into that category the additional revert commits shouldn't clutter up the history.
I think, we should have used merge from the beginning. But the merging wasn't directly possible on top of the CVS import and I didn't realize that we could solve that problem as simple as using "git merge -s ours". The only disadvantage of "git merge -s ours" is that it shows all commits in ptp_5_0 as part of the history of master. But eclipse visualizes this nicely as a separate branch so that this doesn't make the log view any more complex than having all branches shown (which is currently needed to be able to cherry-pick from the other branch, actually a bit less because it hides the remote tracking branches). I'm sorry that I didn't realize that earlier and that this caused all the confusion with cherry-picking.
See also
(notice that the last two links say that in some cases cherry-pick/rebase is very useful but in the context of contributed work or topic branches - not long running release branches)
Roland
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
