[hibernate-dev] ORM 6 branch

[Yoann Rodiere]

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
>>>>>>
>>>>>