[Nut-upsdev] reposurgeon progress

[Eric S. Raymond]

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:43Z!clepple+nut at gmail.com)
>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:43Z!clepple+nut at gmail.com) 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>