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> 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>
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>
> 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>
>> 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>
>>> 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>
>>>> wrote:
>>>>
>>>>> On Tue, Nov 27, 2018 at 7:22 AM Davide D'Alto
<davide(a)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(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>