On Mo, 13 Apr 2015, Bram Moolenaar wrote: > Markus Heidelberg wrote: > > Hello Bram, > > currently I'm pretty busy aside from computer, so it all takes a while. > > But here it is, the first part of cleanup in HG. A Git cleanup process > > will follow after having finished this step. > > > > Am Mittwoch, 1. April 2015, 21:52:41 schrieb Bram Moolenaar: > > > > > > I generally like cleaning up, but at the same time we should not spend > > > time on things nobody will really care about. > > > > For me, a proper project history from developer view is equal to good > > documentation from user view. > > > > So I gladly invest the time for coming up with a cleanup process. I try > > to keep the effort for you to a minimum. > > > > > Adding tags to old > > > commits is not very useful. In fact, github already has a problem with > > > the number of tags that Vim has. > > > > You don't want to add missing tags because some GitHub tools can't > > handle them properly? :-) > > > > Adding the missing tags makes the repository more complete, they should > > not have been absent in the first place, this just happened by accident. > > Adding < 20 tags (now < 10 in the cleanup script below) is a drop in the > > ocean of the > 3000 existing tags. > > At least the missing minor releases (7.2 7.3) should be added, but I > > don't see a reason for not completing the few other tags. > > > > The huge number of tags are one reason for my suggestion to rethink > > versioning from my previous mail. > > > > > Removing empty and useless meta data sounds useful. > > > Branches were only used temporarily, I don't think they contain useful > > > information. > > > > I checked that they don't contain additional content or information. > > In HG we have to close the branches (see script below), later in Git > > they can be deleted. > > > > > I don't think I will want to change the commit messages because some git > > > tools can't handle them properly. AFAIK the message do show up properly > > > in most places. > > > > Git wants to structure plain text commit messages into subject and body > > for summary resp. extended description. There has to be some convention > > and Git does it in the simplest possible way by using the first > > line/paragraph as subject for the short log and including the following > > paragraphs for the full log. > > > > So when declaring Git as the official repository, I'd expect it to be > > used as it is intended to and then it would be obvious to follow this > > convention. > > > > This is also not just some Git tool, it is the Git reference > > implementation. The reason other tools (GitHub or GUIs) might not depend > > on the blank line to separate the summary from the full log is just to > > improve visual representation. > > > > > Some things can perhaps be done on the Mercurial repository before the > > > import, but I suppose some are only possible in git. What will happen > > > for the mirror in Mercurial then? We need to make sure we don't break > > > anything. > > > > Yes, makes sense. > > I was not familiar with Mercurial, only knew some commands for basic > > usage, so I had to dig in first to understand the concepts behind it - > > especially the differences in branches, tags and publishing compared to > > Git. > > > > To avoid breaking the HG repo/mirror, cleanup requiring history rewrite > > has to be restricted to the Git repo. > > > > Below the script, it is completely non-interactive: > > Thanks for figuring this out. > > I have little experience with Mercurial and git (who needs version > control, I have multi-level persistent undo! :-). I would need a > thorough review from a couple of people before running this.
We could first check it with the bitbucket vim playground repository. It's my experimental repository and it contains some extra commits for getting the tags right (my script wasn't working correctly, but I think, I just fixed it today). And if we screw up, I can set it up again ;) (I already said I am going to reimport from the google code repository once that one is frozen, so it is not much extra effort). Best, Christian -- -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
