Re: New spin of repository conversion

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

On 10/18/2017 12:58 PM, Eric S. Raymond wrote:
> I've pushed a version including the 1.1 release in its tail, and all
> previously missing tags should now be visible.

The new repository clones much faster now.  Thanks.

Also, at first glance it appears that the authorship has mapped as 
expected.  That's a nice achievement.

The main issue still is the loss of branch information.  That's 
something we have to retain.  In gitg the graph shows no branches, and 
of course there are no branches other than "master" in the "Branches" 
list, since that's what caught my attention.  However, in git-gui/gitk 
if I request "Visualize all branch history", the commit history graph 
does, in fact, show a bifurcation and different colors for branches, 
*but* it's only doing so for the 5.2 series branch, as oppose to going 
all the way back to 4.0 series.  So, it looks to me as though the tag 
information is present, and the branch SHA information is present, but 
the very important head names for the branches has been lost.


> There are somewhere around 275 commits with empty comment fields.
> These should either have comments filled in or, if they are ChanegLog
> singletons that need to be glued to another clique, I need to know
> that.

I'm looking into this amending of commit messages.  I think it was Mojca 
who said such things are possible, and yes it does look possible but it 
is a rather advanced and rather clunky thing to do after the fact.  It 
involves rebase, and I don't think we should have main developers doing 
too much rebase as it is really risky in terms of messing up the origin. 
  Basically, rebase is like cutting "future" changesets from some trunk, 
and moving those future changesets to somewhere else in the repository. 
To change an old commit means rebasing at the particular location one 
wants to change the message, "amend" the message for that head of the 
trunk, and then put back the future changesets on top of that amended 
changeset.  To do such a thing for 270 *** empty log message ***, is 
just out of the question.

I was imagining there was some tool in a GUI that would easily amend an 
old commit message, but I don't think such an option exists.

Eric, from your perspective, is this a difficult task modifying old 
commit messages at the time of construction if you were given a list of 
the following format?

git log --format='<%cE!%cIZ> %s'

For maintainers, a bit of discussion here about whether we should take 
the time right now to go back and fill in those commit messages that are 
empty.  Here is how one would identify the missing messages:

git log --format='<%cE!%cIZ> %s' | grep " empty log message "

We'd have to redirect that output to a file and then manually edit the 
commit message for all those entries.  And I think the easiest way to 
quickly jump to the changeset, with the diff hunks, is to use a git GUI 
(gitk, gitg, qgit, etc.) that has a search feature (in gitg, search for 
"empty log message").


> I've enclosed a file named EMPTY which is in the right format to be
> read back in by reposurgeon. All of you, please fill in any comments
> you can in the commits you're responsible for; if you want to clue me
> in to a ChangeLog commit that should be squashed with the previous
> one, put SQUASH in the comment field.  Don't alter the divider lines.
> 
> The tags could use some cleanup.

The tag modification isn't as complicated as the commit-message 
amending, right?  I think for tags we can easily use a git GUI to place 
a new tag alongside the old tag, then delete the old tag.  As for naming 
convention I'll leave that up to others, but I would think that making 
the release tag format the same as the tarball file name is most 
logical--whether the tarball names should be changed, I don't know 
(could create confusion out there in the Internet universe).

Dan