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>