After some tries, here's my workflow for applying commits from the 3.6 branch to the master branch: 1. Commit to 3.6 :) 2. Create patches for the commits using git format-patch commit sha/range etc. This will produce numbered patches. 3. Switch to master 4. Modify the patches using the following script: #!/bin/bash for file in $* do sed 's/\/envers\//\/hibernate-envers\//' < $file > mod_$file done (substitute envers with the appropriate module) 5. Apply the patches using git am <file> 6. Done Not very straightforward, but works. And maybe somebody will find a better way :)

I'll report the first time I'll have to do that. Adam On Oct 29, 2010, at 8:11 PM, Steve Ebersole wrote: > Curious what happens if you go the other direction (imho the more natural > direction)? Working from master to the 3.6 branch... > > On Friday, October 29, 2010, at 01:02 pm, Adam Warski wrote: >> After some tries, here's my workflow for applying commits from the 3.6 >> branch to the master branch: 1. Commit to 3.6 :) >> 2. Create patches for the commits using git format-patch commit >> sha/range etc. This will produce numbered patches. 3. Switch to master >> 4. Modify the patches using the following script: >> >> #!/bin/bash >> for file in $* >> do >> >> sed 's/\/envers\//\/hibernate-envers\//' < $file > mod_$file >> >> done >> >> (substitute envers with the appropriate module) >> >> 5. Apply the patches using git am <file> >> 6. Done >> >> Not very straightforward, but works. And maybe somebody will find a >> better way :) > > --- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org

Why do you need two branches? HHH-5706-lob-offset and HHH-5706-lob-offset-backport? Why not have a single topic branch, HHH-5706-lob-offset, and merge it to both 3.6 and master? On Nov 1, 2010, at 10:02 PM, Steve Ebersole wrote: > This morning I had a bug fix from an IRC discussion and decided to use it to > try this stuff out. I chose to work on this on a topic branch created from > master. I ran into worse trouble than you had :) > > About 6 hours on #git helped me get a working answer, though not any better > understanding. The basic steps in the process were: > 1) create a backport branch from the original feature branch. > 2) use rebase -i to perform the actual backport > 3) merge to the target branch > > My complete workflow was as follows: > 1) Create the topic branch: > git checkout -b HHH-5706-lob-offset > > 2) Do my work > > 3) Commit work to the topic branch > git commit ... > > 4) Create a backport branch > git checkout -b HHH-5706-lob-offset-backport HHH-5706-lob-offset > > 5) Git rebase changes to backport branch > git rebase --onto 3.6 master > > 6) Git merge the backport to the 3.6 branch > git checkout 3.6 > git merge HHH-5706-lob-offset-backport > > 7) Git merge topic branch to master > git checkout master > git merge HHH-5706-lob-offset > > 8) Push changes > git push > > 9) Clean up > git branch -d HHH-5706-lob-offset > git branch -d HHH-5706-lob-offset-backport > > > Lot of work. Lot of the folks on #git seemed to empathize that this is a bit > more convoluted than it might should be. > > Another option I was looking at with them keeping along the lines of separate > clones for work on the 3.6 and master branches was to use refs (origin for > example) between the local 3.6 and master clones. In fact you can clone one > to the other locally! > > > > > > On Friday, October 29, 2010, at 01:19 pm, Adam Warski wrote: >> I'll report the first time I'll have to do that. >> >> Adam >> >> On Oct 29, 2010, at 8:11 PM, Steve Ebersole wrote: >>> Curious what happens if you go the other direction (imho the more natural >>> direction)? Working from master to the 3.6 branch... >>> >>> On Friday, October 29, 2010, at 01:02 pm, Adam Warski wrote: >>>> After some tries, here's my workflow for applying commits from the 3.6 >>>> branch to the master branch: 1. Commit to 3.6 :) >>>> 2. Create patches for the commits using git format-patch commit >>>> sha/range etc. This will produce numbered patches. 3. Switch to master >>>> 4. Modify the patches using the following script: >>>> >>>> #!/bin/bash >>>> for file in $* >>>> do >>>> >>>> sed 's/\/envers\//\/hibernate-envers\//' < $file > mod_$file >>>> >>>> done >>>> >>>> (substitute envers with the appropriate module) >>>> >>>> 5. Apply the patches using git am <file> >>>> 6. Done >>>> >>>> Not very straightforward, but works. And maybe somebody will find a >>>> better way :) >>> >>> --- >>> Steve Ebersole <steve(a)hibernate.org&gt; >>> http://hibernate.org > > --- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Why do you need two branches? HHH-5706-lob-offset and HHH-5706-lob-offset-backport? Why not have a single topic branch, HHH-5706-lob-offset, and merge it to both 3.6 and master? On Nov 1, 2010, at 10:02 PM, Steve Ebersole wrote: > This morning I had a bug fix from an IRC discussion and decided to use it > to try this stuff out. I chose to work on this on a topic branch > created from master. I ran into worse trouble than you had :) > > About 6 hours on #git helped me get a working answer, though not any > better understanding. The basic steps in the process were: > 1) create a backport branch from the original feature branch. > 2) use rebase -i to perform the actual backport > 3) merge to the target branch > > My complete workflow was as follows: > 1) Create the topic branch: > git checkout -b HHH-5706-lob-offset > > 2) Do my work > > 3) Commit work to the topic branch > git commit ... > > 4) Create a backport branch > git checkout -b HHH-5706-lob-offset-backport HHH-5706-lob-offset > > 5) Git rebase changes to backport branch > git rebase --onto 3.6 master > > 6) Git merge the backport to the 3.6 branch > git checkout 3.6 > git merge HHH-5706-lob-offset-backport > > 7) Git merge topic branch to master > git checkout master > git merge HHH-5706-lob-offset > > 8) Push changes > git push > > 9) Clean up > git branch -d HHH-5706-lob-offset > git branch -d HHH-5706-lob-offset-backport > > > Lot of work. Lot of the folks on #git seemed to empathize that this is a > bit more convoluted than it might should be. > > Another option I was looking at with them keeping along the lines of > separate clones for work on the 3.6 and master branches was to use refs > (origin for example) between the local 3.6 and master clones. In fact > you can clone one to the other locally! > > On Friday, October 29, 2010, at 01:19 pm, Adam Warski wrote: >> I'll report the first time I'll have to do that. >> >> Adam >> >> On Oct 29, 2010, at 8:11 PM, Steve Ebersole wrote: >>> Curious what happens if you go the other direction (imho the more >>> natural direction)? Working from master to the 3.6 branch... >>> >>> On Friday, October 29, 2010, at 01:02 pm, Adam Warski wrote: >>>> After some tries, here's my workflow for applying commits from the 3.6 >>>> branch to the master branch: 1. Commit to 3.6 :) >>>> 2. Create patches for the commits using git format-patch commit >>>> sha/range etc. This will produce numbered patches. 3. Switch to master >>>> 4. Modify the patches using the following script: >>>> >>>> #!/bin/bash >>>> for file in $* >>>> do >>>> >>>> sed 's/\/envers\//\/hibernate-envers\//' < $file > mod_$file >>>> >>>> done >>>> >>>> (substitute envers with the appropriate module) >>>> >>>> 5. Apply the patches using git am <file> >>>> 6. Done >>>> >>>> Not very straightforward, but works. And maybe somebody will find a >>>> better way :) >>> >>> --- >>> Steve Ebersole <steve(a)hibernate.org&gt; >>> http://hibernate.org > > --- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache

I tried cherry picking, doesn't work because the module rename (envers -> hibernate-envers) isn't detected. I'll try Steve's way with the next pull request. Adam On Nov 5, 2010, at 1:45 PM, Galder Zamarreño wrote: > Also, would not cherry pick work for you? > > On Nov 5, 2010, at 1:30 PM, Galder Zamarreño wrote: > >> Why do you need two branches? HHH-5706-lob-offset and HHH-5706-lob-offset-backport? >> >> Why not have a single topic branch, HHH-5706-lob-offset, and merge it to both 3.6 and master? >> >> On Nov 1, 2010, at 10:02 PM, Steve Ebersole wrote: >> >>> This morning I had a bug fix from an IRC discussion and decided to use it to >>> try this stuff out. I chose to work on this on a topic branch created from >>> master. I ran into worse trouble than you had :) >>> >>> About 6 hours on #git helped me get a working answer, though not any better >>> understanding. The basic steps in the process were: >>> 1) create a backport branch from the original feature branch. >>> 2) use rebase -i to perform the actual backport >>> 3) merge to the target branch >>> >>> My complete workflow was as follows: >>> 1) Create the topic branch: >>> git checkout -b HHH-5706-lob-offset >>> >>> 2) Do my work >>> >>> 3) Commit work to the topic branch >>> git commit ... >>> >>> 4) Create a backport branch >>> git checkout -b HHH-5706-lob-offset-backport HHH-5706-lob-offset >>> >>> 5) Git rebase changes to backport branch >>> git rebase --onto 3.6 master >>> >>> 6) Git merge the backport to the 3.6 branch >>> git checkout 3.6 >>> git merge HHH-5706-lob-offset-backport >>> >>> 7) Git merge topic branch to master >>> git checkout master >>> git merge HHH-5706-lob-offset >>> >>> 8) Push changes >>> git push >>> >>> 9) Clean up >>> git branch -d HHH-5706-lob-offset >>> git branch -d HHH-5706-lob-offset-backport >>> >>> >>> Lot of work. Lot of the folks on #git seemed to empathize that this is a bit >>> more convoluted than it might should be. >>> >>> Another option I was looking at with them keeping along the lines of separate >>> clones for work on the 3.6 and master branches was to use refs (origin for >>> example) between the local 3.6 and master clones. In fact you can clone one >>> to the other locally! >>> >>> >>> >>> >>> >>> On Friday, October 29, 2010, at 01:19 pm, Adam Warski wrote: >>>> I'll report the first time I'll have to do that. >>>> >>>> Adam >>>> >>>> On Oct 29, 2010, at 8:11 PM, Steve Ebersole wrote: >>>>> Curious what happens if you go the other direction (imho the more natural >>>>> direction)? Working from master to the 3.6 branch... >>>>> >>>>> On Friday, October 29, 2010, at 01:02 pm, Adam Warski wrote: >>>>>> After some tries, here's my workflow for applying commits from the 3.6 >>>>>> branch to the master branch: 1. Commit to 3.6 :) >>>>>> 2. Create patches for the commits using git format-patch commit >>>>>> sha/range etc. This will produce numbered patches. 3. Switch to master >>>>>> 4. Modify the patches using the following script: >>>>>> >>>>>> #!/bin/bash >>>>>> for file in $* >>>>>> do >>>>>> >>>>>> sed 's/\/envers\//\/hibernate-envers\//' < $file > mod_$file >>>>>> >>>>>> done >>>>>> >>>>>> (substitute envers with the appropriate module) >>>>>> >>>>>> 5. Apply the patches using git am <file> >>>>>> 6. Done >>>>>> >>>>>> Not very straightforward, but works. And maybe somebody will find a >>>>>> better way :) >>>>> >>>>> --- >>>>> Steve Ebersole <steve(a)hibernate.org&gt; >>>>> http://hibernate.org >>> >>> --- >>> Steve Ebersole <steve(a)hibernate.org&gt; >>> http://hibernate.org >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> -- >> Galder Zamarreño >> Sr. Software Engineer >> Infinispan, JBoss Cache >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Adam Warski http://www.warski.org http://www.softwaremill.eu

On Nov 2, 2010, at 5:02 AM, Steve Ebersole wrote: > This morning I had a bug fix from an IRC discussion and decided to use it > to try this stuff out. I chose to work on this on a topic branch > created from master. I ran into worse trouble than you had :) > > About 6 hours on #git helped me get a working answer, though not any > better understanding. The basic steps in the process were: > 1) create a backport branch from the original feature branch. > 2) use rebase -i to perform the actual backport > 3) merge to the target branch > > My complete workflow was as follows: > 1) Create the topic branch: > git checkout -b HHH-5706-lob-offset > > 2) Do my work > > 3) Commit work to the topic branch > git commit ... > > 4) Create a backport branch > git checkout -b HHH-5706-lob-offset-backport HHH-5706-lob-offset > > 5) Git rebase changes to backport branch > git rebase --onto 3.6 master > > 6) Git merge the backport to the 3.6 branch > git checkout 3.6 > git merge HHH-5706-lob-offset-backport > > 7) Git merge topic branch to master > git checkout master > git merge HHH-5706-lob-offset > > 8) Push changes > git push > > 9) Clean up > git branch -d HHH-5706-lob-offset > git branch -d HHH-5706-lob-offset-backport seems this method does not work well when the commit contains some new add files, https://github.com/hibernate/hibernate-core/commit/1a43593c868e5e16bda01bd 90f500660a26ced2a i just did one commit follow this, and see the change paths: Changed paths: M core/src/main/antlr/hql.g A hibernate-core/src/test/java/org/hibernate/test/hql/EntityBean.java A hibernate-core/src/test/java/org/hibernate/test/hql/EntityBeanTest.java A hibernate-core/src/test/java/org/hibernate/test/hql/Item.java > Lot of work. Lot of the folks on #git seemed to empathize that this is a > bit more convoluted than it might should be. > > Another option I was looking at with them keeping along the lines of > separate clones for work on the 3.6 and master branches was to use refs > (origin for example) between the local 3.6 and master clones. In fact > you can clone one to the other locally! > > On Friday, October 29, 2010, at 01:19 pm, Adam Warski wrote: >> I'll report the first time I'll have to do that. >> >> Adam >> >> On Oct 29, 2010, at 8:11 PM, Steve Ebersole wrote: >>> Curious what happens if you go the other direction (imho the more >>> natural direction)? Working from master to the 3.6 branch... >>> >>> On Friday, October 29, 2010, at 01:02 pm, Adam Warski wrote: >>>> After some tries, here's my workflow for applying commits from the 3.6 >>>> branch to the master branch: 1. Commit to 3.6 :) >>>> 2. Create patches for the commits using git format-patch commit >>>> sha/range etc. This will produce numbered patches. 3. Switch to master >>>> 4. Modify the patches using the following script: >>>> >>>> #!/bin/bash >>>> for file in $* >>>> do >>>> >>>> sed 's/\/envers\//\/hibernate-envers\//' < $file > mod_$file >>>> >>>> done >>>> >>>> (substitute envers with the appropriate module) >>>> >>>> 5. Apply the patches using git am <file> >>>> 6. Done >>>> >>>> Not very straightforward, but works. And maybe somebody will find a >>>> better way :) >>> >>> --- >>> Steve Ebersole <steve(a)hibernate.org&gt; >>> http://hibernate.org > > --- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev