James McCoy wrote: > On Thu, Apr 23, 2015 at 9:19 AM, Christian Brabandt wrote: > > On Do, 23 Apr 2015, Daniel Hahler wrote:
> >> in the process of moving the repository to Github I suggest using the > >> existing mirror from https://github.com/vim-jp/vim as a starting > >> point. > > > > As a starting point for what? I think what is going to happen, is that > > the googlecode repository will be migrated into github (probably using > > the Export to Github button) > > Using that export mangles the history of the repository by, at > the very least, removing all traces of the .hgtags file. This > means that there will be no shared history between > https://github.com/vim/vim and any existing Git mirror (e.g., > vim-jp's mirror, my mirror, MacVim's mirror, etc.). This also > means that any Mercurial mirror of the Git mirror won't have the > same history as the existing Mercurial repository. Even if the .hgtags weren't mangled, it is unlikely that Google's export would result in the same history. > If there's a desire to change the contents of the repository, > that should simply be done after the conversion to Git, instead > of changing published history. Can you elaborate on what you mean with this? What change to the contents of the repo do you mean? > > and then development will continue from > > there one. This has the advantage, that the issues will be migrated as > > well. > > That's a high cost just to get issues migrated. Is it possible to > only migrate issues or disable the mangling of the repository's > history? We could use the migrate functionality, which would convert the issues, but then force-push any other repo over it, e.g. the vim-jp's vim mirror. > >> This would make it easier for existing patches / pull requests (based > >> on this AFAIK most popular Git mirror) to get integrated into Vim > >> itself later, because of the then common history. > >> > >> Additionally it would make it easier/trivial for users that are using > >> this mirror to migrate to Vim's new repository. > > > > If I am not mistaken, it's simply a matter of adding another remote to > > your .git/config file. What would be the problem with that? > > If people are just going to rebase their patches, then there's no > problem. If instead they want to merge future Vim development into > their existing branches, then the lack of a shared history is a > problem. Yes, the problem is basically that there would be no common history between the original (mirror) remote and the new one. This would also make rebasing more difficult already (as in "git rebase"), and you would have to manually apply the patches (via "git am"). Cheers, Daniel. -- -- 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.
