[hibernate-dev] Missing commits - was Re: Minor issues/questions about Hibernate Core/ORM documentation

Steve Ebersole steve at hibernate.org
Fri Jan 13 11:34:27 EST 2012


We have a "best effort" solution to find stuff that gotten 
over-written.  The premise is that reflog shows these commits, while 
they no longer show up in log.  Thats true unless git locally ran a gc 
on your repo.

Anyway, the idea of the best effort is to compare reflog against log 
for all jira issue keys included in 4.0.1.

Since reflog entries are potentially isolated to each developer's 
machine that did the work, we will get the best picture we can if 
everyone does this process for JIRAs they worked for 4.0.1.  Basically 
find all JIRA keys that you worked on for 4.0.1 that are not referenced 
in the git-log.  If they are still referenced in the git-reflog you can 
recover them by cherry-picking from the reflog commit-id.  Sucks, I 
know :(


On Fri 13 Jan 2012 09:17:48 AM CST, Steve Ebersole wrote:
> Well however it happened at least some commits are missing.
>
> It happened between 4.0 and 4.0.1. So like Sanne said it is best if 
> everyone checks any work they committed to make sure it is still there.
>
> The only way this happens is if someone did a forced push. We have 
> talked about this before. In fact the last time was when I did a force 
> and over-wrote some commits. So whoever pushed upstream with a force, 
> please DO NOT! There is unfortunately no way for us to disable that on 
> GitHub hosted repos. The next step that I really do not want to have 
> to take is to start removing push rights.
>
>
> On 01/12/2012 08:58 PM, Steve Ebersole wrote:
>> Can anyone with better git-fu than me tell me where those changes went?
>>
>> On Thu 12 Jan 2012 08:44:19 PM CST, Steve Ebersole wrote:
>>> Actually wrt aggregateJavadocs, some how all those edits to
>>> release.gradle are gone on master :(
>>>
>>>
>>> On Thu 12 Jan 2012 03:48:46 PM CST, Steve Ebersole wrote:
>>>>
>>>> On Thu 12 Jan 2012 03:19:29 AM CST, Hardy Ferentschik wrote:
>>>>> Answers inline
>>>>>
>>>>> On Jan 12, 2012, at 9:50 AM, Gail Badner wrote:
>>>>>
>>>>>> I've uploaded the 4.0.1.Final documentatation to
>>>>>> http://docs.jboss.org/hibernate/core/4.0/.
>>>>>>
>>>>>> Maybe this was already discussed but, should the switch from "core"
>>>>>> to "orm" affect the URL for the 4.0 documentation (i.e.,
>>>>>> http://docs.jboss.org/hibernate/orm/4.0/)?
>>>>>
>>>>> I think it makes sense to switch the urls. However, in this case I
>>>>> suggest we also put a redirect in place for
>>>>> http://docs.jboss.org/hibernate/core/4.0/ to
>>>>> http://docs.jboss.org/hibernate/orm/4.0/
>>>>> Just renaming the directories is probably not a good idea due to
>>>>> bookmarks and people used to go to the 'core' url. If we change to
>>>>> orm we need to update the pointers from
>>>>> http://www.hibernate.org/docs
>>>>
>>>> I agree, we should do a redirect. I had not planned on changing the
>>>> physical dir until 4.1 as that is when the new docs would be getting
>>>> used. 6 in one... if you feel the itch, go for it.
>>>>
>>>>
>>>>>> Also, I noticed that http://docs.jboss.org/hibernate/stable/core/
>>>>>> points to 3.6.9.Final docs. Should it point to
>>>>>> http://docs.jboss.org/hibernate/core/4.0/ (or
>>>>>> http://docs.jboss.org/hibernate/orm/4.0/)?
>>>>>
>>>>> Stable should definitely point to 4.0. That's independent of whether
>>>>> we rename the urls
>>>> + 1
>>>>
>>>>
>>>>>> I ended up using the documentation downloaded from the SourceForge
>>>>>> distribution because I got errors when I tried to build the Javadoc
>>>>>> from the 4.0.1 tag using "gradle javadoc":
>>>>>>
>>>>>> /NotBackedUp/gbadner/git/hibernate-core-master/hibernate-core/src/main/java/org/hibernate/metamodel/source/annotations/HibernateDotNames.java:109: 
>>>>>>
>>>>>> cannot find symbol
>>>>>> symbol : variable DotName
>>>>>> location: interface
>>>>>> org.hibernate.metamodel.source.annotations.HibernateDotNames
>>>>>> DotName ACCESS_TYPE = DotName.createSimple(
>>>>>> AccessType.class.getName() );
>>>>>>
>>>>>> What command should be used to build Javadoc?
>>>>>
>>>>> 'gradle javadoc' is the default javadoc task which you get when you
>>>>> use the Java plugin. It build the javadocs for the current module.
>>>>> In our case we don't use this task, because
>>>>> we want aggregated docs. To get the aggregated docs you need to run
>>>>> the 'aggregateJavadocs' from the release module.
>>>>>
>>>>> './gradlew aggregateJavadocs'
>>>>
>>>> Just a minor point. If you run it from the release module, it has to
>>>> be `../gradlew aggregateJavadocs`
>>>>
>>>> Alternatively from root you could run `./gradlew
>>>> :release:aggregateJavadocs`
>>>>
>>>>
>>>>> FYI, the javadoc task needs all dependencies on the classpath when
>>>>> executing. Looking at the error it seems jandex is not on the
>>>>> classpath. This might be related to HHH-6921, but that's just a 
>>>>> guess.
>>>>> As said, the default javadocs tasks are not configured, because we
>>>>> are only interested in the aggregated docs.
>>>>
>>>> I think Strong only changed that to move jandex to the provided
>>>> configuration. I was able to run these fine when I did the build.
>>>>
>>>>
>>>>>> I also noticed that the Javadoc includes test classes. It would be
>>>>>> nice to exclude those.
>>>>>
>>>>> right, even the aggregated docs seem to include test classes. I
>>>>> would create a jira and we reconfigure the task for the next release
>>>>
>>>> Hmm, I spent a lot of time getting those right.
>>>> https://fisheye2.atlassian.com/changelog/Hibernate-Core?cs=39d47c4b39f231435305b47e23f4b2cf8e9aede8#releaseZ002frelease.gradle 
>>>>
>>>>
>>>>
>>>> If they are back, something after fucked those changes up.
>>>>
>>>>
>>>>>> I really liked how convenient it was to be able to just copy the
>>>>>> contents of the documentation directory from the distribution into
>>>>>> the staging directory for rsync-ing. The only change I had to make
>>>>>> after copying was to change hem/en to hem/en-US. I haven't looked
>>>>>> into this, but I imagine that would be an easy thing to fix.
>>>>
>>>> We should update that in the source tree. But to be honest, hem docs
>>>> should really just go away as a separate thing. Their content should
>>>> be merged into the main docs.
>>>>
>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

-- 
steve at hibernate.org
http://hibernate.org



More information about the hibernate-dev mailing list