Well first, I never said it would be deleted after the Alpha. I said it would be deleted *at some point*, meaning at some point after 6 is moved to master.

Well first, I never said it would be deleted after the Alpha. I said it would be deleted *at some point*, meaning at some point after 6 is moved to master.

On Tue, Nov 27, 2018 at 7:22 AM Davide D'Alto <davide(a)hibernate.org&gt; wrote: > +1 for the creation of the branch upstream and everything Yoann said. > > One curiosity, once there is an alpha, why would you delete the whole > branch? > Couldn't you change everything on the existing branch without deleting it? > It's unusual to rewrite the history of upstream branches but we have > done it before. > Well first, I never said it would be deleted after the Alpha. I said it would be deleted *at some point*, meaning at some point after 6 is moved to master. Also, IMO, topic branches upstream are generally speaking a very bad idea. So this is something we hardly ever do - maybe y'all do on other projects, dunno. But either way, it is very common for a topic branch to go away eventually. As far as re-writing history, sure it is unusual but we are already in the realm of unusual merely by having a topic branch upstream _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

We seem to be "arguing" the same thing. As I said above, I am fine with moving it upstream. Just making sure everyone has the same expectations (re-writing, eventual removal, etc) of that upstream branch because they are not typical of our upstream branches. I would not really call it "hidden away", but I agree that it should be easy to access. Not sure what you mean about your "labelling" point. Label how? Maybe you are referring to the "expectations"? I agree that the name `wip/...` already implies these expectations. Again, that is exactly why we borrowed that convention from Vlad in the first place. On Tue, Nov 27, 2018 at 8:27 AM Yoann Rodiere <yoann(a)hibernate.org&gt; wrote: > I may be wrong, but I understood your message as an argument that moving > 6.0 to upstream would be bad, because having a topic branch upstream is not > a good practice. > > Topic branches are typically short-lived and focus on a specific feature > or bugfix. I agree topic branches in upstream would be a mess. > > But let's be honest: wip/6.0 has been around for years, includes tons of > different improvements, and has impacts in many places of the codebase > (nearly 10,000 files from what I can see) . It hardly qualifies as a topic > branch anymore, and even if we extend the definition to include such a > massive changeset, we can probably agree it's not your typical "change a > dozen files and we're done" topic branch. Wouldn't an atypical branch call > for an atypical workflow? > > Besides... and perhaps more importantly, it's the branch everyone seems > to be working on these days. Once 6.0.0.Alpha1 has been released, it would > seem odd for all that work to be hidden away in someone's fork, be it the > project leader's. If the branch is regularly rewritten, so be it: at least > it should be easily found. > > Again, no problem with labelling it differently to make clear that we > offer no guarantee of a stable history on that branch. To me, the name > "wip/6.0" makes this very clear already. > > > Yoann Rodière > Hibernate NoORM Team > yoann(a)hibernate.org > > On Tue, 27 Nov 2018 at 14:42, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > >> On Tue, Nov 27, 2018 at 7:22 AM Davide D'Alto <davide(a)hibernate.org&gt; >> wrote: >> >> > +1 for the creation of the branch upstream and everything Yoann said. >> > >> > One curiosity, once there is an alpha, why would you delete the whole >> > branch? >> > Couldn't you change everything on the existing branch without deleting >> it? >> > It's unusual to rewrite the history of upstream branches but we have >> > done it before. >> > >> >> Well first, I never said it would be deleted after the Alpha. I said it >> would be deleted *at some point*, meaning at some point after 6 is moved >> to >> master. >> >> Also, IMO, topic branches upstream are generally speaking a very bad >> idea. >> So this is something we hardly ever do - maybe y'all do on other >> projects, >> dunno. But either way, it is very common for a topic branch to go away >> eventually. >> >> As far as re-writing history, sure it is unusual but we are already in >> the >> realm of unusual merely by having a topic branch upstream >> > _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >

Then Chris and Andrea might as well push it to upstream as soon as they are done integrating the latest changes from master. On Tue, Nov 27, 2018 at 9:01 AM Yoann Rodiere <yoann(a)hibernate.org&gt; wrote: > Yes, it seems we all agree then. Great :) > > About the "labelling" part, yes, that's what I meant. > > Yoann Rodière > Hibernate NoORM Team > yoann(a)hibernate.org > > > On Tue, 27 Nov 2018 at 15:52, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > >> We seem to be "arguing" the same thing. As I said above, I am fine with >> moving it upstream. Just making sure everyone has the same expectations >> (re-writing, eventual removal, etc) of that upstream branch because they >> are not typical of our upstream branches. >> >> I would not really call it "hidden away", but I agree that it should be >> easy to access. >> >> Not sure what you mean about your "labelling" point. Label how? Maybe >> you are referring to the "expectations"? I agree that the name `wip/...` >> already implies these expectations. Again, that is exactly why we borrowed >> that convention from Vlad in the first place. >> >> >> On Tue, Nov 27, 2018 at 8:27 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >> wrote: >> >>> I may be wrong, but I understood your message as an argument that >>> moving 6.0 to upstream would be bad, because having a topic branch upstream >>> is not a good practice. >>> >>> Topic branches are typically short-lived and focus on a specific >>> feature or bugfix. I agree topic branches in upstream would be a mess. >>> >>> But let's be honest: wip/6.0 has been around for years, includes tons >>> of different improvements, and has impacts in many places of the codebase >>> (nearly 10,000 files from what I can see) . It hardly qualifies as a topic >>> branch anymore, and even if we extend the definition to include such a >>> massive changeset, we can probably agree it's not your typical "change a >>> dozen files and we're done" topic branch. Wouldn't an atypical branch call >>> for an atypical workflow? >>> >>> Besides... and perhaps more importantly, it's the branch everyone seems >>> to be working on these days. Once 6.0.0.Alpha1 has been released, it would >>> seem odd for all that work to be hidden away in someone's fork, be it the >>> project leader's. If the branch is regularly rewritten, so be it: at least >>> it should be easily found. >>> >>> Again, no problem with labelling it differently to make clear that we >>> offer no guarantee of a stable history on that branch. To me, the name >>> "wip/6.0" makes this very clear already. >>> >>> >>> Yoann Rodière >>> Hibernate NoORM Team >>> yoann(a)hibernate.org >>> >>> On Tue, 27 Nov 2018 at 14:42, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> On Tue, Nov 27, 2018 at 7:22 AM Davide D'Alto <davide(a)hibernate.org&gt; >>>> wrote: >>>> >>>> > +1 for the creation of the branch upstream and everything Yoann said. >>>> > >>>> > One curiosity, once there is an alpha, why would you delete the >>>> whole >>>> > branch? >>>> > Couldn't you change everything on the existing branch without >>>> deleting it? >>>> > It's unusual to rewrite the history of upstream branches but we have >>>> > done it before. >>>> > >>>> >>>> Well first, I never said it would be deleted after the Alpha. I said >>>> it >>>> would be deleted *at some point*, meaning at some point after 6 is >>>> moved to >>>> master. >>>> >>>> Also, IMO, topic branches upstream are generally speaking a very bad >>>> idea. >>>> So this is something we hardly ever do - maybe y'all do on other >>>> projects, >>>> dunno. But either way, it is very common for a topic branch to go away >>>> eventually. >>>> >>>> As far as re-writing history, sure it is unusual but we are already in >>>> the >>>> realm of unusual merely by having a topic branch upstream >>>> >>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>

It works the other way: as long as there is a reference to a commit (a tag, a branch), the commit stays in the repository. Unreferenced commits get garbage-collected. So you can definitely tag something even if you rewrite the corresponding branch later. The tag will point to a commit that doesn't exist anymore on you branch, but that's to be expected. To be clear you'll end up with something like this: * [Tip of branch: wip/6.0] Commit B (rewritten) | * Commit A (rewritten) | | * [Tag: 6.0.0.Alpha1] Commit B (original) | | | * Commit A (original) | | * | Some commit that was added on master (5.4): on branch wip/6.0 only | | | / * Common ancestor (some | ... That looks reasonable to be considering you want to rewrite history on wip/6.0. You can avoid it and keep a flat structure, but it will require different strategies that don't involve rewriting history (e.g. merging 5.4 into wip/6.0 instead of rebasing). Yoann Rodière Hibernate NoORM Team yoann(a)hibernate.org On Tue, 27 Nov 2018 at 16:43, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > One thing that just occurred to me and Jan confirmed on Gitter... > Maintaining those tags will be impossible as long as we have to continue to > re-write history for 6.0 to integrate changes from master - merge is just > not an option there. After each re-write the commits that those tags point > to are gone. > > > On Tue, Nov 27, 2018 at 9:02 AM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Then Chris and Andrea might as well push it to upstream as soon as they >> are done integrating the latest changes from master. >> >> On Tue, Nov 27, 2018 at 9:01 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >> wrote: >> >>> Yes, it seems we all agree then. Great :) >>> >>> About the "labelling" part, yes, that's what I meant. >>> >>> Yoann Rodière >>> Hibernate NoORM Team >>> yoann(a)hibernate.org >>> >>> >>> On Tue, 27 Nov 2018 at 15:52, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> We seem to be "arguing" the same thing. As I said above, I am fine >>>> with moving it upstream. Just making sure everyone has the same >>>> expectations (re-writing, eventual removal, etc) of that upstream branch >>>> because they are not typical of our upstream branches. >>>> >>>> I would not really call it "hidden away", but I agree that it should >>>> be easy to access. >>>> >>>> Not sure what you mean about your "labelling" point. Label how? >>>> Maybe you are referring to the "expectations"? I agree that the name >>>> `wip/...` already implies these expectations. Again, that is exactly why >>>> we borrowed that convention from Vlad in the first place. >>>> >>>> >>>> On Tue, Nov 27, 2018 at 8:27 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> I may be wrong, but I understood your message as an argument that >>>>> moving 6.0 to upstream would be bad, because having a topic branch upstream >>>>> is not a good practice. >>>>> >>>>> Topic branches are typically short-lived and focus on a specific >>>>> feature or bugfix. I agree topic branches in upstream would be a mess. >>>>> >>>>> But let's be honest: wip/6.0 has been around for years, includes tons >>>>> of different improvements, and has impacts in many places of the codebase >>>>> (nearly 10,000 files from what I can see) . It hardly qualifies as a topic >>>>> branch anymore, and even if we extend the definition to include such a >>>>> massive changeset, we can probably agree it's not your typical "change a >>>>> dozen files and we're done" topic branch. Wouldn't an atypical branch call >>>>> for an atypical workflow? >>>>> >>>>> Besides... and perhaps more importantly, it's the branch everyone >>>>> seems to be working on these days. Once 6.0.0.Alpha1 has been released, it >>>>> would seem odd for all that work to be hidden away in someone's fork, be it >>>>> the project leader's. If the branch is regularly rewritten, so be it: at >>>>> least it should be easily found. >>>>> >>>>> Again, no problem with labelling it differently to make clear that we >>>>> offer no guarantee of a stable history on that branch. To me, the name >>>>> "wip/6.0" makes this very clear already. >>>>> >>>>> >>>>> Yoann Rodière >>>>> Hibernate NoORM Team >>>>> yoann(a)hibernate.org >>>>> >>>>> On Tue, 27 Nov 2018 at 14:42, Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> On Tue, Nov 27, 2018 at 7:22 AM Davide D'Alto <davide(a)hibernate.org&gt; >>>>>> wrote: >>>>>> >>>>>> > +1 for the creation of the branch upstream and everything Yoann >>>>>> said. >>>>>> > >>>>>> > One curiosity, once there is an alpha, why would you delete the >>>>>> whole >>>>>> > branch? >>>>>> > Couldn't you change everything on the existing branch without >>>>>> deleting it? >>>>>> > It's unusual to rewrite the history of upstream branches but we >>>>>> have >>>>>> > done it before. >>>>>> > >>>>>> >>>>>> Well first, I never said it would be deleted after the Alpha. I >>>>>> said it >>>>>> would be deleted *at some point*, meaning at some point after 6 is >>>>>> moved to >>>>>> master. >>>>>> >>>>>> Also, IMO, topic branches upstream are generally speaking a very bad >>>>>> idea. >>>>>> So this is something we hardly ever do - maybe y'all do on other >>>>>> projects, >>>>>> dunno. But either way, it is very common for a topic branch to go >>>>>> away >>>>>> eventually. >>>>>> >>>>>> As far as re-writing history, sure it is unusual but we are already >>>>>> in the >>>>>> realm of unusual merely by having a topic branch upstream >>>>>> >>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>>