<div dir="ltr">From my past experience, if a commit caused a conflict when merging, we always asked the author to fix it and do the merge.<div><br></div><div>After a while it became a habit that each dev who submitted a code that could result in conflicts, did all the merges. </div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 27, 2017 at 12:37 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">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 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 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. Finally,<br class="gmail_msg">
> this approach allows the codebase to diverge from maintenance 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 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 (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 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 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 to do<br class="gmail_msg">
> a merge with strategy `ours` (`git merge -s ours 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, 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 done very<br class="gmail_msg">
> often. So I assume there won't be any problems most of the 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 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 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">
> <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>