This is a consolidated reply to your four most recent emails. > I am trying to leverage reposurgeon to automate the process of finding merge > points, and I seem to be spinning my wheels. Can you provide an example of how > you are searching for merges?
Not a working one, yet. That code is buggy. It's my next thing to work on. >reposurgeon% merge (apcsmart-dev) >reposurgeon: :11392 cannot merge clean at target :11808 >reposurgeon: target :11808 is out of date on these files: >docs/man/apcsmart.txt drivers/apcsmart.h drivers/apcsmart.c > ># This doesn't seem to be the right merge point, but maybe that's because >'(apcsmart-dev)' represents the whole branch. That's correct. <apcsmart-dev> is the syntax to reference the tip commit. > I am not sure why this merge is so far down the trunk - it was definitely > merged before v2.6.2. As I said, the merge code is buggy. It's one of the two algorithmic issues I still need to work on. After I fix the things that are plain bugs. ># 2. set-eol-style operations get lost; see tags windows-set-eol, reset-eol. > >Again, I think we're okay with that. But I don't have a Windows setup to test >with. I now have that under "# Known problems that are not resolvable." You may have to do something about it after conversion, but it's effectively off my list. >> # 3. Should the first Eaton_SDK commit after the deleteall have a link >> # back to trunk? > >Yes, and not to the deleteall (which should be tagified). OK, noted. I was assuming that the deleteall should be tagified or removed. In fact that's already an operation in the lift recipe. This is the other algorithmic issue. The problem I have to deal with is not just patching this one link back to trunk, it's that I don't yet understand under which circumstances my translator should generate merge commits on its own. >> Also, some remaining zero-fileop commits on the root branch should >> probably be tagified. > >I haven't had a chance to look at the last two. I have. It's nothing - they're from branch deletions, or from branch renames that never need to get expressed in gitspace because there are no file operations after the renames. >I'd add this to the list: "5. with multiple fossil references in a line, only >the first gets lifted." I've already dealt with the problem this would solve by inserting line feeds where the action stamps need horizontal room. >I think it might be time to revisit the alternate style I proposed a >while back (which can probably be handled through editing *.box) where >we use a footnote-like syntax. If this were automated (and I wouldn't >mind taking a shot at it) we could also add short Git hashes to help >with quickly navigating through the tree in gitk (since they turn into >clickable links). This is a cosmetic issue. Hold that thought, and let's revisit once I have the implementation bugs fixed and the algorithmic stuff solved. >Long-term it might be nice to patch gitk to understand your commit ID format. I'd do that if I undertood the gitk code well enough. But it's pretty hairy, and my Tcl-fu is weak. How's yours? > Also attached is a patch to fix the help for several commands (they did not > print anything in the interactive mode). Applied, thanks. >> # 4. Is the new_UIs-root tag still useful? It doesn't seem to point >> # at an actual branch. > >ESR: In terms of content, no - not useful. OK, crossed off my list. >I think we have another case of some deleteall commits masking some other >problem. From the reposurgeon Git repository, the commit "Moving >branches/Development into trunk." (2006-02-16T13:31:[email protected]) >is a deleteall, but in our existing 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: Yes, this is probably related to the fact that I'm not generating both parent links on the Eaton_SDK branch where I should. >I'll look to see how we merged branches/Testing and trunk. Please do. Giving me a good grasp on how the topology of the git commit graph is wrong in those cases will be essential to getting it right. >I just discovered that the svn:ignore properties are not converting to >.gitignore files properly. It looks like the regression happened between >2.0-pre4 and -pre5, although it could well be that the configuration files >bundled with those versions are deleting the necessary metadata. > >In the git output of 2.0-pre5 and later, all of the .gitignore files >contain the following: > >Makefile >config.log >config.status > >even the ones in subdirectories where config.log would not be expected. Hmmm. I instrumented reposurgeon to show all instances of .gitignore generation, and I'm not spotting any that are obviously wrong to me. 2.0-pre7 and auxiliary files have been uploaded to http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz so you can duplicate this test; just set "verbose 2". Summary of current known issues: # 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. # 3. Charles thinks .gitignore generation is busted since pre5, but I # don't see how. I'm going to work on 1 and 2. If you can give me a precise report of deviation from expected behavior 3 shouldn't be hard to fix. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
