>From my past experience, if a commit caused a conflict when merging, we always asked the author to fix it and do the merge.
After a while it became a habit that each dev who submitted a code that could result in conflicts, did all the merges. On Mon, Mar 27, 2017 at 12:37 PM Radim Vansa <rva...@redhat.com> wrote: > If you can't merge a commit (based on 9.0.x) to master clearly, do you > need to file another PR anyway? Then the lag to get some code to master > increases a lot. I am not sure how useful is git tag --contains <sha1> > if you cannot be sure that you'll find all occurrences due to this kind > of issues. > > R. > > On 03/27/2017 11:33 AM, Sebastian Laskawiec wrote: > > Hey! > > > > We are about to start working on 9.1.x and 9.2.y branches so I would > > like to propose alternative merging strategy. > > > > Our current workflow looks like this: > > > > X - new commit > > X` - cherry pick to maintenance branch > > --+-------------------+-------X----- master > > | \------X`---- 9.2.x > > \---------------------------X``--- 9.1.x > > > > Each commit needs to be reviewed in master branch and backported to > > the maintenance branches. From maintenance perspective this is a bit > > painful, since in above example we need to get 3 times through PR > > queue. Also it's worth to mention that X is not X` nor X``. > > Cherry-picking creates a copy of a commit. This makes some useful > > tricks (like git tag --contains <sha1>) a bit harder to use. Finally, > > this approach allows the codebase to diverge from maintenance branches > > very fast (someone might just forget to backport some of the > > refactoring stuff). > > > > The proposal: > > > > X, Y - new commits > > / - merge commits > > --+---------+------/----/--- master > > | \----/---Y/---- 9.2.x > > \-------------X/---------- 9.1.x > > > > With the proposal, a developer should always implement a given feature > > in the lowest possible maintenance branch. Then we will run a set of > > merges from 9.1.x into 9.2.x and finally into master. The biggest > > advantage of this approach is that given functionality (identified by > > a commit) will have the same SHA1 for all branches. This will allow > > all tools like (mentioned before) `git tag --contains <sha1>` to work. > > There are also some further implications of this approach: > > > > * Merging commits should be performed very often (even automatically > > in the night (if merged without any problems)). > > * After releasing each maintenance release, someone will need to do > > a merge with strategy `ours` (`git merge -s ours upstream/9.2.x`). > > This way we will not have to solve version conflicts in poms. > > * Since there is no nice way to rebase a merge commit, they should > > be pushed directly into the master branch (without review, without > > CI). After the merge, HEAD will change and CI will > > automatically pick the build. Remember, merges should be done very > > often. So I assume there won't be any problems most of the times. > > * Finally, with this approach the code diverges slight slower (at > > least from my experience). Mainly because we don't need to > > remember to cherry-pick individual commits. They are automatically > > "taken" by a merge. > > > > From my past experience, this strategy works pretty nice and can be > > almost fully automated. It significantly lowers the maintenance pain > > around cherry-picks. However there is nothing for free, and we would > > need to get used to pushing merged directly into master (which is fine > > to me but some of you might not like it). > > > > Thanks, > > Sebastian > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa <rva...@redhat.com> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
