[hibernate-dev] ORM 6 branch

[Steve Ebersole]

Good to know.  Thanks!

On Tue, Nov 27, 2018 at 10:15 AM Yoann Rodiere <yoann at 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
> yoann at hibernate.org
>
>
> On Tue, 27 Nov 2018 at 16:43, Steve Ebersole <steve at 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 <steve at 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 <yoann at 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
>>>> yoann at hibernate.org
>>>>
>>>>
>>>> On Tue, 27 Nov 2018 at 15:52, Steve Ebersole <steve at 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 <yoann at 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
>>>>>> yoann at hibernate.org
>>>>>>
>>>>>> On Tue, 27 Nov 2018 at 14:42, Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, Nov 27, 2018 at 7:22 AM Davide D'Alto <davide at 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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>