Am Samstag, 15. August 2015, 15:33:54 schrieb Bram Moolenaar: > > Markus Heidelberg wrote: > > > > > > > Oh, I just noticed, of course we cannot just use a new git > > > > > > repository/project on GitHub, otherwise the issues are gone. > > > > > > The final official repository has to be pushed to one created by the > > > > > > Google exporter therefore. > > > > > > > > > > For the one that's there now I created the repository on github and > > > > > then > > > > > pushed the locally converted repo to there. Is there something wrong > > > > > with it, compared to using the one created by the Google exporter? > > > > > So far I thought it would be fine, so long as the name ends up being > > > > > the > > > > > same. > > > > > > > > The name does not matter. The current vim/vim repository does not > > > > contain the issues exported from Google Code, they reside in > > > > vim/vim-old-tryout as well as the single pull request. They move with > > > > the rename of the repository/project. > > > > > > Oh, the issues are on the repository, not on the project. I see. > > > > I guess you mean "organization" instead of "project" here, > > github.com/vim in this case. > > > > The projects (vim/vim or vim/vim-old-tryout) each contain their own > > repository and issue database. > > > > > Well, I didn't see them, since issues were disabled in settings. > > > > > > I didn't get your remark "the issues are gone", I was thinking of > > > repository issues, not Vim issues. > > > > > > Hmm, one can add a repository and delete a repository, but making it > > > totally empty and pushing a fresh repo into it appears not to be > > > possible. > > > > > > So, is the conclusion that we need to push the cleaned-up Mercurial > > > repository to Google code before doing the export? > > > > No, that doesn't make a difference. You can remove outdated branches and > > tags from the Git repository via "git push" and overwrite the master > > branch by force-pushing. > > I found the --mirror argument (among the big pile of arguments that git > has). It appears that "git push --mirror" will delete anything that > isn't in the local repo. Thus it effectively overwrites the github > repo. Perhaps I first need to do this from an empty repo, so that we > are sure everything is deleted.
I gave the --mirror a short try and it seems to work. However, it really creates a mirror of your local repository, that means it also pushes you remote branch references. If you have one, then you have to delete it afterwards with e.g. git push origin :origin/master So it seems to be suitable for the initial push, but the updates of the master branch and the tags later should be done by an ordinary push. > > As Matthew already wrote, you just have to make sure to delete anything > > you don't overwrite. Since there are so many tags, it is best to just > > delete them all. > > OK. Please give the exact commands to be used. git push --mirror should do it. I will test it after the Git cleanup is ready. > BTW: you are working on the git cleanup, but is the Mercurial cleanup > now ready to be committed? AFAIK it all looks OK, so I could apply this > to my local repository and push it to Google code, right? Yes, I started with the Git cleanup script. During that I found another tag, which should be slightly moved (to the parent commit) to avoid pointing to an empty Git commit after conversion. In the Git cleanup all empty commits are removed. So here is a little update to the HG cleanup script: ========= diff --git a/hg-cleanup.sh b/hg-cleanup.sh index f257220..39cf0fb 100644 --- a/hg-cleanup.sh +++ b/hg-cleanup.sh @@ -59,6 +59,7 @@ hg update -C default # determine the actually wrong tags after manual inspection # v7-4-415 +# v7-3-143 # v7-2-446 # v7-2-443 # v7-2-442 @@ -99,6 +100,7 @@ hg tag -f -r f838615313cd5832efa624526a7575668fb40da9 v7-2-441 hg tag -f -r b0ebf9d121ff99eb2e1697a35dca528e7ecb8f4c v7-2-442 hg tag -f -r 0c1e413c32f1f3f8e28ebf8a030cedeeb664cd46 v7-2-443 hg tag -f -r b619655b31db9469f6fe41932daff7a566079097 v7-2-446 +hg tag -f -r afb476746692322523f167c218803317b87623e3 v7-3-143 hg tag -f -r 353442863d8558dc89d35ef349b60ebb2e38de0e v7-4-415 hg tag -r v7-2-167fix v7-2-167 hg tag --remove v7-2-167fix @@ -115,7 +117,7 @@ matched version 7.2.167. The others have been moved to the correct changeset. EOF -hg rebase --dest rebasedest --source tip~18 --collapse --logfile logfile.txt +hg rebase --dest rebasedest --source tip~19 --collapse --logfile logfile.txt rm logfile.txt # remove unused tag ========= In my initial mail about repository cleanup from 2015-04-01 I added the following item: * Rename tags to match the normal version notation: s/-/./g e.g. v7-4-683 -> v7.4.683 What do you think about this one? If you want to apply it, then this has to be done in the HG as well to have the same tag names in HG and Git repositories and to be consistent in the tag names of the HG mirror. If you don't like it, then I'd discard this idea. Maybe you can comment on some other items from the old mail as well. -- -- 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.
