On Fri, Nov 18, 2016 at 3:29 PM, Kaushal M <kshlms...@gmail.com> wrote: > On Fri, Nov 18, 2016 at 2:04 PM, Kaushal M <kshlms...@gmail.com> wrote: >> On Fri, Nov 18, 2016 at 1:22 PM, Kaushal M <kshlms...@gmail.com> wrote: >>> On Fri, Nov 18, 2016 at 1:17 PM, Kaushal M <kshlms...@gmail.com> wrote: >>>> IMPORTANT: Till this is fixed please stop merging changes into release-3.7 >>>> >>>> I made a mistake. >>>> >>>> When tagging v3.7.17, I noticed that the release-notes at 8b95eba were >>>> not correct. >>>> So I corrected it with a new commit, c11131f, directly on top of my >>>> local release-3.7 branch (I'm sorry that I didn't use gerrit). And I >>>> tagged this commit as 3.7.17. >>>> >>>> Unfortunately, when pushing I just pushed the tags and didn't push my >>>> updated branch to release-3.7. Because of this I inadvertently created >>>> a new (virtual) branch. >>>> Any new changes merged in release-3.7 since have happened on top of >>>> 8b95eba, which was the HEAD of release-3.7 when I made the mistake. So >>>> v3.7.17 exists as a virtual branch now. >>>> >>>> The current branching for release-3.7 and v3.7.17 looks like this. >>>> >>>> | release-3.7 CURRENT HEAD >>>> | >>>> | new commits >>>> | | c11131f (tag: v3.7.17) >>>> 8b95eba --------------------/ >>>> | >>>> | old commits >>>> >>>> The easiest fix now is to merge release-3.7 HEAD into v3.7.17, and >>>> push this as the new release-3.7. >>>> >>>> | release-3.7 NEW HEAD >>>> |release-3.7 CURRENT HEAD -->| Merge commit >>>> | | >>>> | new commits* | >>>> | | c11131f (tag: v3.7.17) >>>> | 8b95eba -------------------/ >>>> | >>>> | old commits >>>> >>>> I'd like to avoid doing a rebase because it would lead to changes >>>> commit-ids, and break any existing clones. >>>> >>>> The actual commands I'll be doing on my local system are: >>>> (NOTE: My local release-3.7 currently has v3.7.17, which is equivalent >>>> to the 3.7.17 branch in the picture above) >>>> ``` >>>> $ git fetch origin # fetch latest origin >>>> $ git checkout release-3.7 # checking out my local release-3.7 >>>> $ git merge origin/release-3.7 # merge updates from origin into my >>>> local release-3.7. This will create a merge commit. >>>> $ git push origin release-3.7:release-3.7 # push my local branch to >>>> remote and point remote release-3.7 to my release-3.7 ie. the merge >>>> commit. >>>> ``` >>>> >>>> After this users with existing clones should get changes done on their >>>> next `git pull`. >>> >>> I've tested this out locally, and it works. >>> >>>> >>>> I'll do this in the next couple of hours, if there are no objections. >>>> >> >> If forgot to give credit. Thanks JoeJulian and gnulnx for noticing >> this and bringing attention to it. > > I'm going ahead with the plan. I've not gotten any bad feedback. On > JoeJulian and Niels said it looks okay.
This is now done. A merge commit 94ba6c9 was created which merges back v3.7.17 into release-3.7. The head of release-3.7 now points to this merge commit. Future pulls of release-3.7 will not be affected. If anyone faces issues, please let met know. > >> >>>> ~kaushal _______________________________________________ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
