Good to know. Thanks! On Tue, Nov 27, 2018 at 10:15 AM Yoann Rodiere <yo...@hibernate.org> wrote:
> 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 > yo...@hibernate.org > > > On Tue, 27 Nov 2018 at 16:43, Steve Ebersole <st...@hibernate.org> 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 <st...@hibernate.org> >> 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 <yo...@hibernate.org> >>> 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 >>>> yo...@hibernate.org >>>> >>>> >>>> On Tue, 27 Nov 2018 at 15:52, Steve Ebersole <st...@hibernate.org> >>>> 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 <yo...@hibernate.org> >>>>> 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 >>>>>> yo...@hibernate.org >>>>>> >>>>>> On Tue, 27 Nov 2018 at 14:42, Steve Ebersole <st...@hibernate.org> >>>>>> wrote: >>>>>> >>>>>>> On Tue, Nov 27, 2018 at 7:22 AM Davide D'Alto <dav...@hibernate.org> >>>>>>> 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@lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>> >>>>>> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
