<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03/27/2017 12:45 PM, Sebastian Laskawiec wrote:<br class="gmail_msg">
> From my past experience, if a commit caused a conflict when merging,<br class="gmail_msg">
> we always asked the author to fix it and do the merge.<br class="gmail_msg">
<br class="gmail_msg">
I don't understand. The PR should be filed against 9.0.x, there're no<br class="gmail_msg">
conflicts. Merging the same against master results in conflicts - where<br class="gmail_msg">
should I resolve those?<br class="gmail_msg"></blockquote><div><br></div><div>I think we mean 9.1.x (the oldest maintenance branch). In that case you should merge 0.9.1 into 0.9.2. Than another merge 0.9.2 into master.</div><div><br></div><div>Once the conflict occurs, a developer who does the merge should simply resolve it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Another q: I decide to file a PR against 9.1, because I don't think it<br class="gmail_msg">
should be applied to 9.0. I get a review, but then someone explains that<br class="gmail_msg">
it should get to 9.0 as well. I can't change a target branch in GitHub's<br class="gmail_msg">
PR: should I close the PR with nice history of comments (some of them<br class="gmail_msg">
not addressed yet) and open another PR?<br class="gmail_msg"></blockquote><div><br></div><div>You can do both (if depends on your intuition which is better). The nice thing about git merge is that it won't throw any error if a change is already present on target branch. So it is possible and legal to cherry-pick stuff as well. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
R.<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> After a while it became a habit that each dev who submitted a code<br class="gmail_msg">
> that could result in conflicts, did all the merges.<br class="gmail_msg">
><br class="gmail_msg">
> On Mon, Mar 27, 2017 at 12:37 PM Radim Vansa <<a href="mailto:rvansa@redhat.com" class="gmail_msg" target="_blank">rvansa@redhat.com</a><br class="gmail_msg">
> <mailto:<a href="mailto:rvansa@redhat.com" class="gmail_msg" target="_blank">rvansa@redhat.com</a>>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> If you can't merge a commit (based on 9.0.x) to master clearly, do you<br class="gmail_msg">
> need to file another PR anyway? Then the lag to get some code to<br class="gmail_msg">
> master<br class="gmail_msg">
> increases a lot. I am not sure how useful is git tag --contains <sha1><br class="gmail_msg">
> if you cannot be sure that you'll find all occurrences due to this<br class="gmail_msg">
> kind<br class="gmail_msg">
> of issues.<br class="gmail_msg">
><br class="gmail_msg">
> R.<br class="gmail_msg">
><br class="gmail_msg">
> On 03/27/2017 11:33 AM, Sebastian Laskawiec wrote:<br class="gmail_msg">
> > Hey!<br class="gmail_msg">
> ><br class="gmail_msg">
> > We are about to start working on 9.1.x and 9.2.y branches so I would<br class="gmail_msg">
> > like to propose alternative merging strategy.<br class="gmail_msg">
> ><br class="gmail_msg">
> > Our current workflow looks like this:<br class="gmail_msg">
> ><br class="gmail_msg">
> > X - new commit<br class="gmail_msg">
> > X` - cherry pick to maintenance branch<br class="gmail_msg">
> > --+-------------------+-------X----- master<br class="gmail_msg">
> > | \------X`---- 9.2.x<br class="gmail_msg">
> > \---------------------------X``--- 9.1.x<br class="gmail_msg">
> ><br class="gmail_msg">
> > Each commit needs to be reviewed in master branch and backported to<br class="gmail_msg">
> > the maintenance branches. From maintenance perspective this is a bit<br class="gmail_msg">
> > painful, since in above example we need to get 3 times through PR<br class="gmail_msg">
> > queue. Also it's worth to mention that X is not X` nor X``.<br class="gmail_msg">
> > Cherry-picking creates a copy of a commit. This makes some useful<br class="gmail_msg">
> > tricks (like git tag --contains <sha1>) a bit harder to use.<br class="gmail_msg">
> Finally,<br class="gmail_msg">
> > this approach allows the codebase to diverge from maintenance<br class="gmail_msg">
> branches<br class="gmail_msg">
> > very fast (someone might just forget to backport some of the<br class="gmail_msg">
> > refactoring stuff).<br class="gmail_msg">
> ><br class="gmail_msg">
> > The proposal:<br class="gmail_msg">
> ><br class="gmail_msg">
> > X, Y - new commits<br class="gmail_msg">
> > / - merge commits<br class="gmail_msg">
> > --+---------+------/----/--- master<br class="gmail_msg">
> > | \----/---Y/---- 9.2.x<br class="gmail_msg">
> > \-------------X/---------- 9.1.x<br class="gmail_msg">
> ><br class="gmail_msg">
> > With the proposal, a developer should always implement a given<br class="gmail_msg">
> feature<br class="gmail_msg">
> > in the lowest possible maintenance branch. Then we will run a set of<br class="gmail_msg">
> > merges from 9.1.x into 9.2.x and finally into master. The biggest<br class="gmail_msg">
> > advantage of this approach is that given functionality<br class="gmail_msg">
> (identified by<br class="gmail_msg">
> > a commit) will have the same SHA1 for all branches. This will allow<br class="gmail_msg">
> > all tools like (mentioned before) `git tag --contains <sha1>` to<br class="gmail_msg">
> work.<br class="gmail_msg">
> > There are also some further implications of this approach:<br class="gmail_msg">
> ><br class="gmail_msg">
> > * Merging commits should be performed very often (even<br class="gmail_msg">
> automatically<br class="gmail_msg">
> > in the night (if merged without any problems)).<br class="gmail_msg">
> > * After releasing each maintenance release, someone will need<br class="gmail_msg">
> to do<br class="gmail_msg">
> > a merge with strategy `ours` (`git merge -s ours<br class="gmail_msg">
> upstream/9.2.x`).<br class="gmail_msg">
> > This way we will not have to solve version conflicts in poms.<br class="gmail_msg">
> > * Since there is no nice way to rebase a merge commit, they should<br class="gmail_msg">
> > be pushed directly into the master branch (without review,<br class="gmail_msg">
> without<br class="gmail_msg">
> > CI). After the merge, HEAD will change and CI will<br class="gmail_msg">
> > automatically pick the build. Remember, merges should be<br class="gmail_msg">
> done very<br class="gmail_msg">
> > often. So I assume there won't be any problems most of the<br class="gmail_msg">
> times.<br class="gmail_msg">
> > * Finally, with this approach the code diverges slight slower (at<br class="gmail_msg">
> > least from my experience). Mainly because we don't need to<br class="gmail_msg">
> > remember to cherry-pick individual commits. They are<br class="gmail_msg">
> automatically<br class="gmail_msg">
> > "taken" by a merge.<br class="gmail_msg">
> ><br class="gmail_msg">
> > From my past experience, this strategy works pretty nice and can be<br class="gmail_msg">
> > almost fully automated. It significantly lowers the maintenance pain<br class="gmail_msg">
> > around cherry-picks. However there is nothing for free, and we would<br class="gmail_msg">
> > need to get used to pushing merged directly into master (which<br class="gmail_msg">
> is fine<br class="gmail_msg">
> > to me but some of you might not like it).<br class="gmail_msg">
> ><br class="gmail_msg">
> > Thanks,<br class="gmail_msg">
> > Sebastian<br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > _______________________________________________<br class="gmail_msg">
> > infinispan-dev mailing list<br class="gmail_msg">
> > <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a>><br class="gmail_msg">
> > <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> --<br class="gmail_msg">
> Radim Vansa <<a href="mailto:rvansa@redhat.com" class="gmail_msg" target="_blank">rvansa@redhat.com</a> <mailto:<a href="mailto:rvansa@redhat.com" class="gmail_msg" target="_blank">rvansa@redhat.com</a>>><br class="gmail_msg">
> JBoss Performance Team<br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> infinispan-dev mailing list<br class="gmail_msg">
> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a>><br class="gmail_msg">
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> infinispan-dev mailing list<br class="gmail_msg">
> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Radim Vansa <<a href="mailto:rvansa@redhat.com" class="gmail_msg" target="_blank">rvansa@redhat.com</a>><br class="gmail_msg">
JBoss Performance Team<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
infinispan-dev mailing list<br class="gmail_msg">
<a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
</blockquote></div></div>