As far as I can tell this only affected 2 commits. I have reapplied them both. But please double check any work you did for 4.0.1
On Fri 13 Jan 2012 10:34:27 AM CST, Steve Ebersole wrote: > 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@lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >> > -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
