[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
