| [mdt-papyrus.dev] Merge vs. Rebase |
I haven't seen a discussion about setting up the Papyrus Gerrit to use rebase instead of merge. I've attached a screen shot of a typical section of the Papyrus project's history and a screen shot of a typical section of the CDT project's history. The prevelance of merge nodes and the minor parallel streams makes for confusing code archelogical sessions. This gets even more complicated when tracking multiple release streams (e.g., master and a maintenance branch). The problem is especially visible when contrasted with the CDT's straight-line history. These screenshots aren't really a fair comparison; the CDT project is showing twice as much information! I am tracking only one remote branch in the Papyrus repo and two in the CDT one. I can see why merge nodes might be nice to see your own merge nodes for the past few days development. However the more common case is to exploring other people's changes further in the past. As an example use case, consider investigating a particular section of code using the annotations. I don't really care if the code was merged somewhere, what I care about is the original commit the created the code. Does the Papyrus project have any interest in changing from merge-based to rebase-based :-) development? If this seems like too radical of a change to make, then what about having a merge-based collector branch that is then rebased into a straightline onto master? -Andrew
Attachment:
merge.png
Description: PNG image
Attachment:
rebase.png
Description: PNG image
