Markus Heidelberg wrote: > sorry for the late reply. I'm pretty busy and also needed a bit to find > the proper words. It also takes some time to get into this topic again > after several months of silence.
Thanks for the long reply. > Am Samstag, 8. August 2015, 21:43:13 schrieb Bram Moolenaar: > > > > Markus Heidelberg wrote: > > > > > For me, a proper project history from developer view is equal to good > > > documentation from user view. > > > > It's been some since we looked at this, and the information is now > > scattered over several messages. > > > > Markus, could you make the step-by-step description of what needs to be > > done? I need exact steps and some hints about what to do when there are > > errors. > > My proposal was: > 1. Cleanup in the HG repository > 2. Conversion from HG to Git > 3. Cleanup in the Git repository > > +++ In detail: +++ > > 1. Cleanup in the HG repository > ******************************* > > This is covered by the existing HG cleanup script. Attached again > because compared to the latest version Christian sent today, I've added > a check whether the rebase extension is enabled. I think I already have it enabled, my .hgrc contains: [extensions] hgext.convert= hgext.extdiff= rebase = mq = > Basically it does two things: > - close the unused or invalid branches > - fix and complete the tags > > My test runs I performed like this: > > # copy the original HG repository > cp -a vim-hg vim-hg-copy > > # clone the copy > hg clone vim-hg-copy vim-hg-copycloned > > # run the cleanup script > cd vim-hg-copycloned > sh ../cleanup/hg-cleanup.sh > > # push back from the cloned copy to the initial copy to verify that no > # history has been rewritten, elsewise this command would fail > hg push So, what you are doing here is to simulate pushing back to the Mercurial repository on Google code. Although the "hg push" could also be done on the vim-hg-copy repository, would do the same thing. As I asked on Christian's message: We can do this even before exporting to github, right? > # verify the result manually with "hgk" or "hg log", compare with the > # original repository > cd ../vim-hg-copy > hgk > hg log --style compact --graph > > I don't expect errors, so I can't predict what to do when any will > occur. Just ask in that case. > > 2. Conversion from HG to Git > **************************** > > > I do intend to use the "export to github" feature of the Google code > > site, so that (hopefully) issues will be deep-linked to their new place. > > I do assume that after the Mercurial repository is converted to git, we > > could just wipe it out and replace it with another. > > What does "issues deep-linking" mean exactly? Automatically redirecting > from an issue URL on the old Google site to an issue URL on the new > GitHub site? I don't know about the dimension of > > "In the future, the page will automatically redirect to well-known > project hosting services" > > from the Exporter FAQ [1], but it sounds neither are you sure about this > topic. > On the other side, is this redirection really that important? I also don't know what it means exactly, but we can at least use this as "the best we'll ever get". > [1] https://code.google.com/p/support-tools/wiki/GitHubExporterFAQ > > I tested the "Export to GitHub" button today. > > I saw the drawbacks with issues conversion, which you already mentioned > in another mail, i.e. the original author and date information is only > added in the comment. Obviously it is not possible to make a relation > from a Google user to a GitHub user. The problem with the date is that > the GitHub API is used for importing, which always uses the current time > of course. > > I don't know which script runs in the background for repository > conversion, but it does not create a completely valid result. > I had already seen this problem in your Git test repository, a local > conversion with the hg-fast-export scripts worked properly and this is > the way I'd go. > > The problems in the repository after online conversion: > > - There are 3 history roots instead of just 1, the branches do start > without parent instead of branching off from a particular commit. > - The merge parents of the two merge commits are in the wrong and > logically less correct order (compare with "git log --graph"). > - The clone is several hundreds MB big, it seems the repository is not > repacked after conversion. Strange, I wonder why this hasn't been > fixed yet. After the repack, it is only 40 MB. So, what we would need to do is use the export to github for whatever functionality it provides, but then wipe the git repository, do the conversion from Mercurial to git locally, and then upload the result to github. Since this is going to be the new root for what everybody uses, we better make sure this is a clean repository. > 3. Cleanup in the Git repository > ******************************** > > There were suggestions to use the Git mirror from vim-jp as base for the > official repository, don't know if this is still an option. Only if there are real advantages. I tend to think not. > Of course this cleanup step, which required history rewrite, would have > to be omitted in that case and I see hardly any benefit in using > vim-jp's repo. > > I won't repeat the cleanup options in the state we are now, but leave it > for after having finished the first step. > > +++ End of details +++ > > > I would rather not take the risk of messing up the Mercurial repository. > > Thus would the best approach be to do the conversion locally and replace > > the git repository on github? We could even try that out now, since the > > github repository is for testing anyway. > > I invested quite a bit of time and I'm not eager to change the HG > cleanup into a Git cleanup, having lots of the spent time wasted. Good do know. I haven't heard a drawback of doing the cleanup in Mercurial. Also, perhaps the bitbucket copy will work better (assuming it will start tracking the git repository after the move). > The cleanup script runs locally on your local repository as described > above. There is nothing, which can be messed up without being able to > recognize it in the result before publishing. And as Christian wrote, it > can always be fixed in case some mess gets published. > But the script won't mess up anything in the first place. Fingers crossed! -- ARTHUR: A scratch? Your arm's off! BLACK KNIGHT: No, it isn't. ARTHUR: Well, what's that then? BLACK KNIGHT: I've had worse. The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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.
