Subtle bug, simple fix. The problem was introduced by my change that used content hashes to avoid issuing duplicate blobs. The generated .gitignore nodes didn't have a Content-Hash header, which meant all .gitignores were treated as though they had the same *empty* hash.
2.0pre8 is at: http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz Please check that the .gitignores look OK when you generate them. I've updated my mirror to r3395 and fixed up comments. Now I'll go back to work onn getting two-parent commits right, or at least matching what git-svn does, # Known problems: # 1. Merge code isn't working. # 2. The first Eaton_SDK commit after the deleteall should have a link # back to trunk. The commit "Moving branches/Development into trunk." # (2006-02-16T13:31:[email protected]) is a deleteall in # reposurgeon's translation, but in the git-svn conversion and original SVN # repository that commit is a no-op (file-wise) that connects/renames the # old branches/Development with the new trunk. Both instances of a general # problem: I don't have rules for when I should be generating merge # commits. 2 is partially solved. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> "Gun control" is a job-safety program for criminals. _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
