On Jan 9, 2012, at 12:58 AM, Eric S. Raymond wrote: > 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.
Ah, I got it backwards - I assumed that <apcsmart-dev> was the root of the branch, not the tip. >> 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. Can the selected merge points be used as-is with "force", or will that only help cases where the algorithm says a merge isn't possible? >> 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. This is separate from the cosmetic issue of line length. In vi or sed terms, this is like using "s///" where "s///g" is needed (but the reference lifting code seems to be looping over the commit message in a way that I don't quite follow). In the converted repository, we shouldn't see any output from 'git log | fgrep '[[SVN:'. It might be just the first in the commit, rather than the first on the line, which is getting lifted. >> 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. Will do. >> 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? I was thinking more in terms of figuring out a sneaky way to get a gitk developer to do the work :-) But that might be hard if they don't have to deal with legacy SCM systems much. >> 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. Working backwards, then: are you seeing the symptom on your end? (That is, all of the .gitignore files have the same content - where the one under drivers/, for instance, should have a list of the driver executables that won't be present in other directories). The smallest interval I narrowed the regression down to in the history of reposurgeon is 2.0-pre4 to 2.0-pre5, but I did not start looking at the differences in the configuration yet. I won't have much time today to look at this, but I will definitely download the new tarball and check everything later. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
