So your merge commit 5ca928 is a merge between dcbc2d (the below commit) and e2d81ab, which is an old commit of mine. I'm not sure how that happened. Did you try doing any rebases on your history that contained merges maybe?
On Sep 3, 2010, at 11:16 AM, Christian Muise wrote: > This is indeed very strange. According to issue 2046 (and my own bisecting > as well) it comes from this commit: > > commit dcbc2da31324e98c9cb3a4bf17c50f029774ae06 > Author: Sebastian Krämer <basti...@gmail.com> > Date: Wed May 5 22:48:18 2010 +0200 > > Implement fast atomic substitution. > > * The main code is in Basic._subs_dict > * It is used automatically by subs when possible. > * Where the default substitution is not good enough this method is > overridden. > * Because of hashing problems (different hash although equal) one > example in the modules documentation has to be changed. > * This commit only couples it very loose to subs. By rewriting subs a > little and integrating it better there will be some more speed > improvement. > > It looks like the pull into the main repo (sympy/sympy/master) did some > wonky things. Attached is a view of gitk from my local master. Maybe a > description of my workflow can give a hint to someone more experienced with > git than I: > - sympy/sympy was forked to haz/sympy > - haz/sympy was branched for my work > - For a while I would pull updates from git.sympy.org to my master. > - After it officially went to github's sympy/sympy, I pulled in changes from > there > - I would pull changes from my master to my branch > > My last step may be what caused the merge madness seen (should be pulling > from the main repo to a branch?). As to the rogue commit, could it be > something that made it to the git.sympy.org version and not the github one? This is unlikely, because the SHA1 hashes would be different. You see, the SHA1 hash of a commit is computed from the commit message, the diff, and the commit that it is applied onto. The last item essentially means that the SHA1 hash of a commit identifies not only that commit, but also its entire history. > > Notice the date on that commit. Now, if you checkout the old master before > this push (2a366ea) and search the log for that commit, you will not find it. > But if you search the log for that commit in the current master, it is there > but back from a while ago (maybe git log sorts by date instead of commit > order ?). > > Anyway, I think we should do > > git revert dcbc2da31324e98c9cb3a4bf17c50f029774ae06 If there are no objections, I will push this in http://github.com/asmeurer/sympy/tree/christian_merge_fix until we get this sorted out. Aaron Meurer > > and push that up to master until we figure out what happened (and the same if > any other commit snuck in), especially considering the issue 2046. > > Christian, did you mess with this commit at any point in time in your work? > > Definitely not. Just pulls from master branches. > > Cheers, > Christian -- You received this message because you are subscribed to the Google Groups "sympy-patches" group. To post to this group, send email to sympy-patc...@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
