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.berin...@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 <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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
