Re: New trial conversion

[Daniel J S. <dan...@ie...>]

On 10/22/2017 11:03 PM, Eric S. Raymond wrote:
> This one is 58ab3388946d9312812c276fa31cc464a617b304

There is a warning at the end that I don't recall in previous versions:

sebald@ ~/gnuplot/test_repository/fifth_sourceforge $ git clone 
https://git.code.sf.net/p/gnuplot/git-main
Cloning into 'git-main'...
remote: Counting objects: 77463, done.
remote: Compressing objects: 100% (14325/14325), done.
remote: Total 77463 (delta 63011), reused 77463 (delta 63011)
Receiving objects: 100% (77463/77463), 20.76 MiB | 590.00 KiB/s, done.
Resolving deltas: 100% (63011/63011), done.
Checking connectivity... done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

When I then open gitk, I see the error message

"Error parsing revisions: unknown revision HEAD"

in a dialog box.  After selecting OK, gitk shows "No commits selected".

Here is what's missing from .git/config compared to a previous conversion:

sebald@ ~/gnuplot/test_repository/fifth_sourceforge/git-main $ diff -u 
../../fourth_sourceforge/git-main/.git/config .git/config
--- ../../fourth_sourceforge/git-main/.git/config	2017-10-20 
17:01:08.244831322 -0500
+++ .git/config	2017-10-22 23:52:56.825037433 -0500
@@ -6,8 +6,3 @@
  [remote "origin"]
  	url = https://git.code.sf.net/p/gnuplot/git-main
  	fetch = +refs/heads/*:refs/remotes/origin/*
-[branch "master"]
-	remote = origin
-	merge = refs/heads/master
-[gitg]
-	mainline = refs/heads/master

I'm guessing, from the graph generated by gitg, that master should 
coincide with tag "git-conversion" as it currently stands.


With gitg, selecting a lot of the tags does not produce a graph:

Tag
---
Up to branch 3.5 produces a graph
3.7.1 through 3.7.3 no graph
4.0.2 produces a graph
4.2.1 through 4.6.2 no graph
4.6.3 produces a graph
4.6.4 through 5.2.1 no graph

The previous revision behaves the same way.


> The longlines corrections are mostly back in.
> 
> I stuck with author-based action stamps, but the rule for filling in
> time of day on a ChangeLog attribution is now much simpler:
> 
>      Due to the limitations of the ChangeLog format, attribution dates on
>      these author records will be set to have the hh:mm:ss part of the
>      committer date and the committer's timezone; then various tricks are
>      tried to correct the timezone, including looking in the author map if
>      there is one. This choice is often close to right (e.g if the
>      committer is the author) and no worse than any other arbitrary
>      assignment would be.
> 
> This should greatly reduce action-stamp collisions, as two
> attributions have only a 1/360th chance of having the same mm:ss
> part.
> 
> There's a more serious issue.
> 
> I've looked at the repo topology in detail and it turns out to be
> rather a mess. Key locations in the repo are as follows.
> 
> redroot    1998-04-15 15:16:47  /Initial import of beta340./
> redright   1998-04-15 15:16:52  /Initial import of beta340./
> redleft    1998-04-15 15:21:47  /*** empty log message ***/
> branch52   2017-05-22 01:05:26  /Tag branchpoint for 5.2;/
> b52left    2017-05-21 08:00:02  /bump versioning to 5.2.rc0/
> b52right   2017-05-22 01:16:28  /Note policy for new patches applied/
> greenroot  1998-06-23 10:11:50  /Import of beta 347./
> greenright 1999-01-14 07:00:00  /Windows linestyle fix./
> v5stable   2014-08-20 08:00:01  /Start of separate branch for version 5 stable/
> bump46     2011-11-22 07:00:07  /Bump stable version to 4.6;/
> start44    2009-05-31 08:00:07  /Start branch for Release 4.4
> jump42     2006-10-01 08:00:05  /Jump to version 4.2, 1st release candidate./
> greenbug   2004-07-07 08:00:01  /Bugfix: Incorrect brace movement/
> 
> The directions 'right' and 'left', and the colors, describe the way
> the graph looks under gitk (colors aren't stable, though).  Here is a
> graph of the branchpoints:
> 
> redroot ---> redleft -> 4.0.2 -> branch52 --> b52left ---> master
>     |                                |
>     |                                +-------> b52right --> 5.2.0 --> 5.2.1
>     +-------> redright -+
>                         |
> +----------------------+
> |
> +-> greenroot ---> greenright ---> 3.7.1 --> 3.7.2  --> 3.7.3
>          |
>          |
> +-------+
> |
> +-> v5stable -> 5.0.[01234567] -> branch-5.0-stable
> |
> +-> bump46 -> 4.6.[0123456] -> branch 4.6-stable
> |
> +-> start44 -> 4.4.[01] -> 4.4.[34] -> branch-4.4-stable
> |
> +-> jump42 -> 4.2.[123456] -> branch-4.2-stable
> |
> +-> greenbug -> branch-4.0-stable
> 
> This is pretty badly wrong.  In fact of the three branch points - redroot,
> greenroot, and branch52 - only branch52 is correct.

It looks to me, in gitg, that branch52 is coming from what would be 
considered "master".

These graphs are such a difficult thing to following in something like 
gitk or gitg, and it's because those tools aren't really geared for nice 
display of branching.  If I select one of the tags in gitg, the graph 
jumps there but it only displays commits up to that tag.  It doesn't put 
in context with all other branches.

I've tried using cvsgraph to generate a graph of where the CVS branches 
occur, but no luck.


> This kind of failure happens in cvs-fast-export as a fallback when it
> encounters incomplete root tags (CVS tags associated with a branch
> root).  I don't completely understand the recovery logic - I didn't
> write it, and the person who did has let the details slip.  What it
> tries to do (I think) is run the join point backward from the
> incomplete root tag until it find something it can recognize as an
> ancestor, duplicating as many common changesets as it needs to to reroot
> the branch.
> 
> To rectify this for each branch, we need to locate the correct branch
> point, the place where the bad root tag happened, and perform a graft.
> Looking at the v5stable commit date of 2014-08-20 14:37:30 we find
> these omn the master branch.
> 
> 42617 2014-08-20T12:00:00Z Empirical adjustments to dashlength calculated a
> 42619 2014-08-20T19:32:14Z Mark as 5.1
> 
> Allowing for EDT time-zone shift it looks like the v5stable commit to
> start the branch took place about 50 minutes before 5.1 was marked,
> so if we transplant v5stable to be a child of /Empirical adjustments
> to dashlength/ and then nuke the older commits on the branch, that should
> restore the original topology.
> 
> Ethan, can you confirm that this fork point is correct?
> 
> We're going to have to do 4 or 5 similar grafts to restore the tree to
> correct topology.

Is it possible to rebase some things after conversion to correct that paths?

Dan