I did a pull+rebase. The rebase had conflicts. But I never found a way to continue the rebase initiated from pull. I thought `git rebase --continue`was the incantation, but it was not working. So I guess conceivably there were additional commits still to process which would explain the missing commits.
Is there a way to revert my forced push and I can try again? On Jun 1, 2011 4:46 AM, "Steve Ebersole" <st...@hibernate.org> wrote: > I did pull. I pulled immediately before the push > On Jun 1, 2011 4:28 AM, "Strong Liu" <st...@hibernate.org> wrote: >> i guess before you force push, you didn't pull >> so, the commits after your last pull just losted after you force push >> >> ----------- >> Strong Liu <st...@hibernate.org> >> http://hibernate.org >> http://github.com/stliu >> >> On Jun 1, 2011, at 5:12 PM, Steve Ebersole wrote: >> >>> I did the force, but to be honest I am still not understanding why this > was >>> a problem. Perhaps I am just misunderstanding what a forced push does. >>> On Jun 1, 2011 3:43 AM, "Sanne Grinovero" <sa...@hibernate.org> wrote: >>>> 2011/6/1 Hardy Ferentschik <ha...@hibernate.org>: >>>>> On Wed, 01 Jun 2011 10:15:54 +0200, Sanne Grinovero >>>>> <sanne.grinov...@gmail.com> wrote: >>>>> >>>>>> Some time ago I experienced a similar issue with Hibernate Core's >>>>>> repository, >>>>>> and solved it by renaming my master, checking out a fresh copy and >>>>>> rebasing in my changes from my local copy. >>>>> >>>>> Right. That was the second option. Keep what was on master on GitHub > and >>>>> rebasing the local changes on top of it. >>>>> We did it the other way around, because we thought that most people >>>>> would have the state we had locally. So restoring this would create > less >>>>> issues. >>>>> >>>>>> From what I understood, (when it happened before) it seemed that >>>>>> somebody had renamed the master from another branch, but I could have >>>>>> messed up differently. >>>>> >>>>> Well, I stay away from renaming master :-) >>>>> In the long run I would like us to move Core development to the same >>>>> development >>>>> style we have in Search and Valiator. Everything is done via pull >>> requests. >>>>> Not only would this prevent situation like this one, but it also >>> increases >>>>> code awareness, since you see what is happening across the whole code >>> base. >>>>> Maybe Search and Validator are a little easier to handle, because we > are >>>>> less >>>>> people working on it, but I think this should not stop us to try a >>> similar >>>>> approach on Core. >>>>> Maybe not a good time to start right away with this due to the amount > of >>>>> changes >>>>> atm, but maybe once the code settles a little more ... >>>> >>>> It's working pretty well on Infinispan, same model as Search but with >>>> a fairly larger team. Sometimes when there's less people involved pull >>>> requests tend to stack up a bit and we need to ping each other for >>>> who's going to volunteer to take X but we never lack volunteers. >>>> I don't think you need it, especially when you need all possible speed >>>> and are releasing alpha versions of a new mayor version. >>>> >>>> Sanne >>>> >>>>> >>>>> --Hardy >>>>> >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
