[infinispan-dev] Branching proposal

[Galder Zamarreño]

Nice one-liner. The fact that we always put the JIRA id helps.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 27 Mar 2017, at 14:36, Dan Berindei <dan.berindei at gmail.com> wrote:
> 
> I use something like this to check what tags contain a particular fix:
> 
> git tag --contains $(git log --grep <JIRA> -1 --format="%h" master)
> 
> True, it's a bit longer, but it stays in the bash/zsh history :)
> 
> Cheers
> Dan
> 
> 
> On Mon, Mar 27, 2017 at 1:33 PM, Radim Vansa <rvansa at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> 
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev