Re: Repository cleanup (Was: Preparations for moving to github)
On Do, 27 Aug 2015, Markus Heidelberg wrote: > The git repository doesn't need it and you can't even test the .hgignore > file in the git repository for correct syntax. There might be subtle > differences, I don't know exactly. I think this is best be left to the > HG mirror to convert .gitignore to .hgignore because it is VCS specific. For now I leave the .hgignore file from the old repository. I don't expect many changes, so I don't think I need to convert the gitignore file to hgignore. Best, Christian -- Dringt durch des Aberglaubens Nacht, Die euch zu finstern Köpfen macht. -- Christian Fürchtegott Gellert (Der Freigeist) -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Mittwoch, 26. August 2015, 20:08:11 schrieb Ben Fritz: > On Tuesday, August 25, 2015 at 12:55:29 PM UTC-5, Markus Heidelberg wrote: > > Am Dienstag, 25. August 2015, 17:42:26 schrieb Christian Brabandt: > > > > > > Did the .gitignore file change between the old googlecode repository and > > > the new github repository? I get a modification here: > > > > > > diff --git a/.gitignore b/.gitignore > > > --- a/.gitignore > > > +++ b/.gitignore > > > @@ -1,5 +1,3 @@ > > > -# This is .gitignore > > > - > > > # Unixen: object and executable files. > > > *.o > > > src/vim > > > > While rewriting history during Git repo cleanup I took the opportunity > > to replace the .hgignore with .gitignore, so that even if you go back in > > time you benefit from the ignore list. > > > > I removed the HG specific "syntax: glob" and subsequent blank line > > without adding this comment, which originates from the .gitignore in the > > HG repo. > > > > > I can commit it in the mirror or you can fix it in the original ;) > > > > This wouldn't be a fix :) > > Since we have an hg mirror, how about keeping both files? The git repository doesn't need it and you can't even test the .hgignore file in the git repository for correct syntax. There might be subtle differences, I don't know exactly. I think this is best be left to the HG mirror to convert .gitignore to .hgignore because it is VCS specific. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Tuesday, August 25, 2015 at 12:55:29 PM UTC-5, Markus Heidelberg wrote: > Am Dienstag, 25. August 2015, 17:42:26 schrieb Christian Brabandt: > > > > Did the .gitignore file change between the old googlecode repository and > > the new github repository? I get a modification here: > > > > diff --git a/.gitignore b/.gitignore > > --- a/.gitignore > > +++ b/.gitignore > > @@ -1,5 +1,3 @@ > > -# This is .gitignore > > - > > # Unixen: object and executable files. > > *.o > > src/vim > > While rewriting history during Git repo cleanup I took the opportunity > to replace the .hgignore with .gitignore, so that even if you go back in > time you benefit from the ignore list. > > I removed the HG specific "syntax: glob" and subsequent blank line > without adding this comment, which originates from the .gitignore in the > HG repo. > > > I can commit it in the mirror or you can fix it in the original ;) > > This wouldn't be a fix :) Since we have an hg mirror, how about keeping both files? -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Christian Brabandt wrote: > On Do, 20 Aug 2015, Bram Moolenaar wrote: > > > I have done the "for real" update of the Vim repository. > > I used the same sequence of commands as for the tryout, thus the result > > should be the same. > > Did the .gitignore file change between the old googlecode repository and > the new github repository? I get a modification here: > > diff --git a/.gitignore b/.gitignore > --- a/.gitignore > +++ b/.gitignore > @@ -1,5 +1,3 @@ > -# This is .gitignore > - > # Unixen: object and executable files. > *.o > src/vim > > I can commit it in the mirror or you can fix it in the original ;) That was changed by the git cleanup script that Markus created. -- Citizens are not allowed to attend a movie house or theater nor ride in a public streetcar within at least four hours after eating garlic. [real standing law in Indiana, United States of America] /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Dienstag, 25. August 2015, 17:42:26 schrieb Christian Brabandt: > > Did the .gitignore file change between the old googlecode repository and > the new github repository? I get a modification here: > > diff --git a/.gitignore b/.gitignore > --- a/.gitignore > +++ b/.gitignore > @@ -1,5 +1,3 @@ > -# This is .gitignore > - > # Unixen: object and executable files. > *.o > src/vim While rewriting history during Git repo cleanup I took the opportunity to replace the .hgignore with .gitignore, so that even if you go back in time you benefit from the ignore list. I removed the HG specific "syntax: glob" and subsequent blank line without adding this comment, which originates from the .gitignore in the HG repo. > I can commit it in the mirror or you can fix it in the original ;) This wouldn't be a fix :) -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Di, 25 Aug 2015, Christian Brabandt wrote: > On Do, 20 Aug 2015, Bram Moolenaar wrote: > > > I have done the "for real" update of the Vim repository. > > I used the same sequence of commands as for the tryout, thus the result > > should be the same. > > Did the .gitignore file change between the old googlecode repository and > the new github repository? I get a modification here: > > diff --git a/.gitignore b/.gitignore [...] I just commit the change. No need to change anything in the official repo. Best, Christian -- Wie man sein Kind nicht nennen sollte: Dick Tator -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Do, 20 Aug 2015, Bram Moolenaar wrote: > I have done the "for real" update of the Vim repository. > I used the same sequence of commands as for the tryout, thus the result > should be the same. Did the .gitignore file change between the old googlecode repository and the new github repository? I get a modification here: diff --git a/.gitignore b/.gitignore --- a/.gitignore +++ b/.gitignore @@ -1,5 +1,3 @@ -# This is .gitignore - # Unixen: object and executable files. *.o src/vim I can commit it in the mirror or you can fix it in the original ;) Best, Christian -- Das ganze Leben besteht aus Wollen und Nichtvollbringen, Vollbringen und Nichtwollen. -- Goethe, Maximen und Reflektionen, Nr. 694 -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
* Bram Moolenaar [150821 16:39]: > The idea is that all events on GitHub are forwarded to the vimdev > maillist. Christian had setup something for that. I believe this also > applies to pull requests. > > I indeed prefer to discuss changes on the maillist, since everybody can > join and it keeps everything in one place. I also plan to keep > including patches as before, not directly using the pull request. > > We'll see how it goes. That sounds good to me. Thanks...Marvin -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Marvin Reply wrote: > There was a longish thread on debian-devel a while back (I can't find it > right now) about using github for development. One of the points raised > was that if you accept github pull requests (from their web UI), then > those developers who do not have (and perhaps do not wish to get) github > accounts cannot participate. If you disallow github pull requests and > only accept git PRs (perhaps with a dedicated mailing list), than anyone > can participate. > > I have never used the github UI, so I don't know how true this is, and I > may have misunderstood what the problems were, but it is at least > something to consider. The idea is that all events on GitHub are forwarded to the vimdev maillist. Christian had setup something for that. I believe this also applies to pull requests. I indeed prefer to discuss changes on the maillist, since everybody can join and it keeps everything in one place. I also plan to keep including patches as before, not directly using the pull request. We'll see how it goes. -- VOICE OVER: As the horrendous Black Beast lunged forward, escape for Arthur and his knights seemed hopeless, when, suddenly ... the animator suffered a fatal heart attack. ANIMATOR: Agh! VOICE OVER: The cartoon peril was no more ... The Quest for Holy Grail could continue. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
* Bram Moolenaar [150821 14:59]: > Looks like most things are ready, I'll soon announce that GitHub is > ready for our business. > > What remains to be filled in is the section "Moving over to github - if > you have local changes" on http://www.vim.org/movetogithub.php > Who has a good text for that? There was a longish thread on debian-devel a while back (I can't find it right now) about using github for development. One of the points raised was that if you accept github pull requests (from their web UI), then those developers who do not have (and perhaps do not wish to get) github accounts cannot participate. If you disallow github pull requests and only accept git PRs (perhaps with a dedicated mailing list), than anyone can participate. I have never used the github UI, so I don't know how true this is, and I may have misunderstood what the problems were, but it is at least something to consider. ...Marvin -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Christian Brabandt wrote: > On Do, 20 Aug 2015, Christian Brabandt wrote: > > > On Do, 20 Aug 2015, Bram Moolenaar wrote: > > > > > http://www.vim.org/develop.php > > also, I think sources.php needs to be adjusted as well. Looks like most things are ready, I'll soon announce that GitHub is ready for our business. What remains to be filled in is the section "Moving over to github - if you have local changes" on http://www.vim.org/movetogithub.php Who has a good text for that? -- "When I die, I want a tombstone that says "GAME OVER" - Ton Richters /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Christian Brabandt wrote: > On Do, 20 Aug 2015, Christian Brabandt wrote: > > > On Do, 20 Aug 2015, Bram Moolenaar wrote: > > > > > http://www.vim.org/develop.php > > also, I think sources.php needs to be adjusted as well. Yes, I'll do that. -- BEDEVERE: Oh! LAUNCELOT: No "Arrggghhh ... " at the back of the throat. BEDEVERE: No! "Oh!" in surprise and alarm! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Christian Brabandt wrote: > On Do, 20 Aug 2015, Bram Moolenaar wrote: > > > http://www.vim.org/develop.php > > There is a link missing for the "mercurial mirror on bitbucket" Added. However, I think we should move the stuff about using MQ to the Mercurial page. > I would prefer to have a section on how to migrate from google code to > bitbucket / git. That's on the page I forgot to mention: http://www.vim.org/movetogithub.php > And if some git expert could write a short explanation on how to develop > patches using git (similar to how to use the mq extension at the > develop.php page), this would be appreciated. Yes. And that would be on the git page. -- User: I'm having problems with my text editor. Help desk: Which editor are you using? User: I don't know, but it's version VI (pronounced: 6). Help desk: Oh, then you should upgrade to version VIM (pronounced: 994). /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Hi vim_dev! On Do, 20 Aug 2015, Christian Brabandt wrote: > On Do, 20 Aug 2015, Bram Moolenaar wrote: > > > http://www.vim.org/develop.php also, I think sources.php needs to be adjusted as well. Best, Christian -- Astrologe: ein Mensch, der aus den Sternen liest, was im Gesicht steht. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Do, 20 Aug 2015, Bram Moolenaar wrote: > http://www.vim.org/develop.php There is a link missing for the "mercurial mirror on bitbucket" I would prefer to have a section on how to migrate from google code to bitbucket / git. And if some git expert could write a short explanation on how to develop patches using git (similar to how to use the mq extension at the develop.php page), this would be appreciated. Best, Christian -- Willst du dir den Tag versauen, mußt du in den Spiegel schauen. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: > > The biggest file there is 33M. No idea how it gets bigger after pushing > > to GitHub. 10M is not something to worry about. Previously it was > > 600M. > > Maybe it has something to do with GitHub's repository management. Or > that the repository was not empty when pushing to it, even though it > does not contain more tags or branches than expected. I have done the "for real" update of the Vim repository. I used the same sequence of commands as for the tryout, thus the result should be the same. I'm now updating the pages that used to refer to Google Code. Some parts are TODO. Some parts could use some more text and examples. Please look at these pages: http://www.vim.org/git.php http://www.vim.org/mercurial.php http://www.vim.org/download.php http://www.vim.org/develop.php Once this looks good I'll announce the move has finished. We can then start using the issue tracker on GitHub. -- BROTHER MAYNARD: Armaments Chapter Two Verses Nine to Twenty One. ANOTHER MONK:And St. Attila raised his hand grenade up on high saying "O Lord bless this thy hand grenade that with it thou mayest blow thine enemies to tiny bits, in thy mercy. "and the Lord did grin and people did feast upon the lambs and sloths and carp and anchovies and orang-utans and breakfast cereals and fruit bats and... BROTHER MAYNARD: Skip a bit brother ... "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Wednesday, August 19, 2015 at 9:03:52 AM UTC-4, Olaf wrote: > On 19-Aug-15, Bram Moolenaar wrote: > > > > Justin M. Keyes wrote: ... > > > Why was the _mercurial_ tag format changed in the google code > > > repository? This breaks all URLs using the old tag format: > > > > > > https://code.google.com/p/vim/source/detail?r=v7-4-827 > > > > > > Now the URL must be formatted like this: > > > > > > https://code.google.com/p/vim/source/detail?r=v7.4.827 How many URLs referring to the old tags are out there and how crucial is it to keep them working? And is there any point trying to do so if code.google.com is going to be shut down anyway? As far as I understand the tags have been changed to confirm to a more conventional format. The move to GitHub is a good opportunity for such a change. > > > What is the purpose of VCS tags if they're going to be changed? It is > > > part of the VCS history. Only new tags should use the new format, not > > > the old tags. VCS tags are just symbolic names that refer to a particular commit. Unlike mercurial, git does not store them in a versioned repository file (.hgtags in Mercurial) so the tags in git can be added, removed or renamed anytime without affecting the repository commit hashes at all. For a consistency and simplicity sake, I would vote for using only the new format and not having multiple tags per commit. Pavol -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Donnerstag, 20. August 2015, 10:55:23 schrieb Bram Moolenaar: > > Markus Heidelberg wrote: > > > Am Mittwoch, 19. August 2015, 23:15:14 schrieb Markus Heidelberg: > > > Am Mittwoch, 19. August 2015, 21:35:52 schrieb Bram Moolenaar: > > > > > > > > I have removed the Ubuntu package for hg-fast-export and downloaded the > > > > individual files from repo.or.cz. The conversion now runs without any > > > > errors or warnings. > > > > > > > > The result is now available at https://github.com/vim/vim-tryout. > > > > Let me know if this is perfect, then I'll push to the vim/vim > > > > repository. And then we can continue from there. > > > > > > I cloned it - it is perfect :) > > > I got the exactly same SHA1 hashes with my local conversion. > > > > But for some reason it takes more space. The packfile in > > .git/objects/pack/ is 42M, but only 32M with my own conversion. Can you > > confirm this in your local repo? This was not the case in your previous > > conversion. > > The biggest file there is 33M. No idea how it gets bigger after pushing > to GitHub. 10M is not something to worry about. Previously it was > 600M. Maybe it has something to do with GitHub's repository management. Or that the repository was not empty when pushing to it, even though it does not contain more tags or branches than expected. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Donnerstag, 20. August 2015, 10:09:39 schrieb Manuel Ortega: > On Thu, Aug 20, 2015 at 4:55 AM, Bram Moolenaar wrote: > > > > > Markus Heidelberg wrote: > > > > > Am Mittwoch, 19. August 2015, 23:15:14 schrieb Markus Heidelberg: > > > > Am Mittwoch, 19. August 2015, 21:35:52 schrieb Bram Moolenaar: Here you removed the relevant part of Bram's post: The result is now available at https://github.com/vim/vim-tryout. > > > > I cloned it - it is perfect :) > > > > > For some reason on github.com/vim/vim, the extra branches that were > supposed to be removed are still there. (vim/vim72/vim73). At one point > they were gone, but now they're back. But there was some renaming and moving anyway, so referring to the repository name was not reliable. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Thu, Aug 20, 2015 at 4:55 AM, Bram Moolenaar wrote: > > Markus Heidelberg wrote: > > > Am Mittwoch, 19. August 2015, 23:15:14 schrieb Markus Heidelberg: > > > Am Mittwoch, 19. August 2015, 21:35:52 schrieb Bram Moolenaar: > > > > I cloned it - it is perfect :) > For some reason on github.com/vim/vim, the extra branches that were supposed to be removed are still there. (vim/vim72/vim73). At one point they were gone, but now they're back. -Manny -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: > Am Mittwoch, 19. August 2015, 23:15:14 schrieb Markus Heidelberg: > > Am Mittwoch, 19. August 2015, 21:35:52 schrieb Bram Moolenaar: > > > > > > I have removed the Ubuntu package for hg-fast-export and downloaded the > > > individual files from repo.or.cz. The conversion now runs without any > > > errors or warnings. > > > > > > The result is now available at https://github.com/vim/vim-tryout. > > > Let me know if this is perfect, then I'll push to the vim/vim > > > repository. And then we can continue from there. > > > > I cloned it - it is perfect :) > > I got the exactly same SHA1 hashes with my local conversion. > > But for some reason it takes more space. The packfile in > .git/objects/pack/ is 42M, but only 32M with my own conversion. Can you > confirm this in your local repo? This was not the case in your previous > conversion. The biggest file there is 33M. No idea how it gets bigger after pushing to GitHub. 10M is not something to worry about. Previously it was 600M. -- An indication you must be a manager: You believe you never have any problems in your life, just "issues" and "improvement opportunities". /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Wed, Aug 19, 2015 at 7:25 PM, Markus Heidelberg wrote: > Am Mittwoch, 19. August 2015, 19:00:36 schrieb Justin M. Keyes: >> On Aug 19, 2015 5:57 PM, "Markus Heidelberg" >> wrote: >> > >> > Am Mittwoch, 19. August 2015, 15:03:38 schrieb Olaf Dabrunz: >> > > On 19-Aug-15, Bram Moolenaar wrote: >> > > > >> > > > Justin M. Keyes wrote: >> > > > >> > > > > On 8/18/15, Bram Moolenaar wrote: >> > > > > > >> > > > > > There were a couple of hiccups, but the repository has moved to >> GitHub >> > > > > > now. It's in the destination place: https://github.com/vim/vim >> > > > > > >> > > > > > Now we need to do the git cleanup. I'll hold off until it looks >> OK, >> > > > > > https://github.com/vim/vim-tryout is what it would look like. >> > > > > > At least it doesn't have the old branches. Apparently the import >> > > > > > resurrected what the Mercurial cleanup was supposed to remove. >> > > > > >> > > > > Why was the _mercurial_ tag format changed in the google code >> > > > > repository? This breaks all URLs using the old tag format: >> > > > > >> > > > > https://code.google.com/p/vim/source/detail?r=v7-4-827 >> > > > > >> > > > > Now the URL must be formatted like this: >> > > > > >> > > > > https://code.google.com/p/vim/source/detail?r=v7.4.827 >> > > > > >> > > > > What is the purpose of VCS tags if they're going to be changed? It >> is >> > > > > part of the VCS history. Only new tags should use the new format, >> not >> > > > > the old tags. >> > >> > In principle you are right, but it is different for this HG repository. >> > >> > AFAIR Bram would have removed the stale HG repository after the move to >> > Git if it were possible, but it wasn't. Then the URLs immediately would >> > not have been accessible anymore. >> > >> > Given that Google Code hosting will close in 5 months and thus the URLs >> > will be broken anyway, I consider this change to be not very harmful at >> > all. >> >> It will be read-only, will it not? That was the purpose of the "deep >> linking" talk, i thought. Old URLs (say, in a repository which will _not_ >> rewrite its history) will continue to point to the patches instead of being >> broken. > > http://google-opensource.blogspot.de/2015/03/farewell-to-google-code.html > > * August 24, 2015 - The site goes read-only. You can still > checkout/view project source, issues, and wikis. > > * January 25, 2016 - The project hosting service is closed. You will > be able to download a tarball of project source, issues, and wikis. > These tarballs will be available throughout the rest of 2016. > > What exactly will be deep-linked, seems to be unclear. I don't think > this feature is important, though. > >> > Furthermore, nobody should use the Google repository anymore from now >> > on, it is outdated with the next patches. >> >> Er, right, except for old URLs referencing those patches, originating from >> sources that cannot be updated. > > Which will stop working in 5 months. It's just that they stop working Ok, I didn't realize that they would actually stop the read-only service. In that case, yes, it is pointless to preserve the tag format for my use case. > earlier now. Broken URLs are not a new phenomenon in the internet. Sure, but I thought that Google gave half a shit, that's all. Offering a VCS service--which implies a commitment to content addressability--also implies that you might want to support the Uniform Resource Locator concept, even if you sunset the service, if the cost of doing so is minimal. > But I don't really care. If the old tags should exist in the Google > repository, I won't have a problem with it, unless they appear in the > new Git repo. No, consider my request canceled. I like the new format for the Git transition. Justin M. Keyes -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Mittwoch, 19. August 2015, 19:00:36 schrieb Justin M. Keyes: > On Aug 19, 2015 5:57 PM, "Markus Heidelberg" > wrote: > > > > Am Mittwoch, 19. August 2015, 15:03:38 schrieb Olaf Dabrunz: > > > On 19-Aug-15, Bram Moolenaar wrote: > > > > > > > > Justin M. Keyes wrote: > > > > > > > > > On 8/18/15, Bram Moolenaar wrote: > > > > > > > > > > > > There were a couple of hiccups, but the repository has moved to > GitHub > > > > > > now. It's in the destination place: https://github.com/vim/vim > > > > > > > > > > > > Now we need to do the git cleanup. I'll hold off until it looks > OK, > > > > > > https://github.com/vim/vim-tryout is what it would look like. > > > > > > At least it doesn't have the old branches. Apparently the import > > > > > > resurrected what the Mercurial cleanup was supposed to remove. > > > > > > > > > > Why was the _mercurial_ tag format changed in the google code > > > > > repository? This breaks all URLs using the old tag format: > > > > > > > > > > https://code.google.com/p/vim/source/detail?r=v7-4-827 > > > > > > > > > > Now the URL must be formatted like this: > > > > > > > > > > https://code.google.com/p/vim/source/detail?r=v7.4.827 > > > > > > > > > > What is the purpose of VCS tags if they're going to be changed? It > is > > > > > part of the VCS history. Only new tags should use the new format, > not > > > > > the old tags. > > > > In principle you are right, but it is different for this HG repository. > > > > AFAIR Bram would have removed the stale HG repository after the move to > > Git if it were possible, but it wasn't. Then the URLs immediately would > > not have been accessible anymore. > > > > Given that Google Code hosting will close in 5 months and thus the URLs > > will be broken anyway, I consider this change to be not very harmful at > > all. > > It will be read-only, will it not? That was the purpose of the "deep > linking" talk, i thought. Old URLs (say, in a repository which will _not_ > rewrite its history) will continue to point to the patches instead of being > broken. http://google-opensource.blogspot.de/2015/03/farewell-to-google-code.html * August 24, 2015 - The site goes read-only. You can still checkout/view project source, issues, and wikis. * January 25, 2016 - The project hosting service is closed. You will be able to download a tarball of project source, issues, and wikis. These tarballs will be available throughout the rest of 2016. What exactly will be deep-linked, seems to be unclear. I don't think this feature is important, though. > > Furthermore, nobody should use the Google repository anymore from now > > on, it is outdated with the next patches. > > Er, right, except for old URLs referencing those patches, originating from > sources that cannot be updated. Which will stop working in 5 months. It's just that they stop working earlier now. Broken URLs are not a new phenomenon in the internet. But I don't really care. If the old tags should exist in the Google repository, I won't have a problem with it, unless they appear in the new Git repo. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Aug 19, 2015 5:57 PM, "Markus Heidelberg" wrote: > > Am Mittwoch, 19. August 2015, 15:03:38 schrieb Olaf Dabrunz: > > On 19-Aug-15, Bram Moolenaar wrote: > > > > > > Justin M. Keyes wrote: > > > > > > > On 8/18/15, Bram Moolenaar wrote: > > > > > > > > > > There were a couple of hiccups, but the repository has moved to GitHub > > > > > now. It's in the destination place: https://github.com/vim/vim > > > > > > > > > > Now we need to do the git cleanup. I'll hold off until it looks OK, > > > > > https://github.com/vim/vim-tryout is what it would look like. > > > > > At least it doesn't have the old branches. Apparently the import > > > > > resurrected what the Mercurial cleanup was supposed to remove. > > > > > > > > Why was the _mercurial_ tag format changed in the google code > > > > repository? This breaks all URLs using the old tag format: > > > > > > > > https://code.google.com/p/vim/source/detail?r=v7-4-827 > > > > > > > > Now the URL must be formatted like this: > > > > > > > > https://code.google.com/p/vim/source/detail?r=v7.4.827 > > > > > > > > What is the purpose of VCS tags if they're going to be changed? It is > > > > part of the VCS history. Only new tags should use the new format, not > > > > the old tags. > > In principle you are right, but it is different for this HG repository. > > AFAIR Bram would have removed the stale HG repository after the move to > Git if it were possible, but it wasn't. Then the URLs immediately would > not have been accessible anymore. > > Given that Google Code hosting will close in 5 months and thus the URLs > will be broken anyway, I consider this change to be not very harmful at > all. It will be read-only, will it not? That was the purpose of the "deep linking" talk, i thought. Old URLs (say, in a repository which will _not_ rewrite its history) will continue to point to the patches instead of being broken. > Furthermore, nobody should use the Google repository anymore from now > on, it is outdated with the next patches. Er, right, except for old URLs referencing those patches, originating from sources that cannot be updated. Justin M. Keyes -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Mittwoch, 19. August 2015, 23:15:14 schrieb Markus Heidelberg: > Am Mittwoch, 19. August 2015, 21:35:52 schrieb Bram Moolenaar: > > > > I have removed the Ubuntu package for hg-fast-export and downloaded the > > individual files from repo.or.cz. The conversion now runs without any > > errors or warnings. > > > > The result is now available at https://github.com/vim/vim-tryout. > > Let me know if this is perfect, then I'll push to the vim/vim > > repository. And then we can continue from there. > > I cloned it - it is perfect :) > I got the exactly same SHA1 hashes with my local conversion. But for some reason it takes more space. The packfile in .git/objects/pack/ is 42M, but only 32M with my own conversion. Can you confirm this in your local repo? This was not the case in your previous conversion. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Mittwoch, 19. August 2015, 15:03:38 schrieb Olaf Dabrunz: > On 19-Aug-15, Bram Moolenaar wrote: > > > > Justin M. Keyes wrote: > > > > > On 8/18/15, Bram Moolenaar wrote: > > > > > > > > There were a couple of hiccups, but the repository has moved to GitHub > > > > now. It's in the destination place: https://github.com/vim/vim > > > > > > > > Now we need to do the git cleanup. I'll hold off until it looks OK, > > > > https://github.com/vim/vim-tryout is what it would look like. > > > > At least it doesn't have the old branches. Apparently the import > > > > resurrected what the Mercurial cleanup was supposed to remove. > > > > > > Why was the _mercurial_ tag format changed in the google code > > > repository? This breaks all URLs using the old tag format: > > > > > > https://code.google.com/p/vim/source/detail?r=v7-4-827 > > > > > > Now the URL must be formatted like this: > > > > > > https://code.google.com/p/vim/source/detail?r=v7.4.827 > > > > > > What is the purpose of VCS tags if they're going to be changed? It is > > > part of the VCS history. Only new tags should use the new format, not > > > the old tags. In principle you are right, but it is different for this HG repository. AFAIR Bram would have removed the stale HG repository after the move to Git if it were possible, but it wasn't. Then the URLs immediately would not have been accessible anymore. Given that Google Code hosting will close in 5 months and thus the URLs will be broken anyway, I consider this change to be not very harmful at all. Furthermore, nobody should use the Google repository anymore from now on, it is outdated with the next patches. The intention was to have proper tag names (matching the version number) in the cleaned up Git repository. Since these should be identical in the new HG mirror, which also shouldn't contain a mess of two different tag naming schemes, the renaming has already been applied to the HG repo before conversion to Git. > > Yeah, it's not nice that old URLs stop working. Unfortunately you are > > too late with this remark, it already happened. We can't make both > > work, can we? > > Git allows multiple tags on a commit, and Mercurial seems to allow that > too (https://mercurial.selenic.com/wiki/Tag). Yes, it is possible with both systems. > Markus, does it work if your script only adds the new tag, keeping the > old one? The script has already been executed and the results pushed. Of course it would be possible to bring the old tags back with an additional commit, but as written above in my opinion this won't make much sense. Christian would have to revert the mess again in his mirror. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Mittwoch, 19. August 2015, 21:35:52 schrieb Bram Moolenaar: > > I have removed the Ubuntu package for hg-fast-export and downloaded the > individual files from repo.or.cz. The conversion now runs without any > errors or warnings. > > The result is now available at https://github.com/vim/vim-tryout. > Let me know if this is perfect, then I'll push to the vim/vim > repository. And then we can continue from there. I cloned it - it is perfect :) I got the exactly same SHA1 hashes with my local conversion. > One thing that's different from the export: That one shows the author as > "brammool", that is my GitHub user account. This gives me statistics > etc. The locally converted repo doesn't have this. Perhaps this is a > matter of changing the email address? Hmm, I can add my b...@vim.org > address to my GitHub account. It didn't have an effect at the toplevel, > but if I now open a commit it works. Perhaps it's just some caching. > I do believe my commits will also use b...@vim.org. The only page (now after you added your vim.org address to the GitHub settings) where brammool is not displayed I can find on the main site: "Bram Moolenaar authored a day ago" instead of "brammool authored ...". Oh, found another one: the branches site. All other sub-sites like commits, contributors, blob, tree, tags have your account mapped. Maybe it's a GitHub bug on the main site. Remember, you configured your Git mail address in ~/.gitconfig with an uppercase "B", maybe some pages are case sensitive? I also used the uppercase b...@vim.org for committer/author mail address unification in the Git cleanup script because that was the address you used the last months for your commits in the experimental Git repository. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Mittwoch, 19. August 2015, 11:59:12 schrieb Bram Moolenaar: > > Markus Heidelberg wrote: > > > Am Dienstag, 18. August 2015, 18:42:50 schrieb Bram Moolenaar: > > > > > > I let the script continue, ignoring the errors. Then I pushed the > > > result to github. I got some errors, I think my sequence of commands is > > > not quite right, probably some can be left out: > > > > > > % git remote add origin g...@github.com:vim/vim.git > > > % git remote -v > > > % git push --mirror > > > % git push --set-upstream origin master > > > % git push --tags > > > % git push origin :origin/master > > > > Should be ok. Tried locally and it looked good, I only got an error with > > the last command because the branch "origin/master" did not exist yet on > > the remote repository and could not be deleted. > > So I just leave out the last command? Yes, it is not necessary in this command sequence because there did not yet exist a remote master branch you could have pushed in addition to the normal master branch. But it doesn't harm either. > > > The result is now at https://github.com/vim/vim. It does have > > > everything up to patch 7.4.827. Does it look OK? > > > > Not quite. Apart from the wrong tag naming there is also a wrong merge > > order in the two merge commits (obtain them with "git log --merges"), > > which already was the case with the direct Google Export. > > Yes, this is the result of the Google export. Or GitHub import from > Google Code, as the conversion is actually done by GitHub. No, this was indeed the result of your local conversion using the old hg-fast-export package and the cleanup. Before you renamed it from vim/vim to vim/vim-tryout. However... > > You said you use the Ubuntu package. I had a look: > > http://packages.ubuntu.com/source/vivid/hg-fast-export > > Even in the latest Ubuntu version 15.04, the package is from 2014-03-08, > > despite having received changes upstream until October 2014. The merge > > order problem has been fixed during that time (log: "do not sort merge > > commit parents"). The same version is used on Debian unstable Sid. > > > > A bit disappointing that obviously an old distro package is used for the > > Google Exporter. As you wrote above, the conversion is done by GitHub. I read it today on the Google Code shutdown announcement: "Please note: GitHub’s importer will convert any Subversion or Mercurial Google Code projects to use Git in the process." http://google-opensource.blogspot.de/2015/03/farewell-to-google-code.html So it's GitHub who uses an old fast-export version and omits the packfile optimization. They should know better. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: > Am Dienstag, 18. August 2015, 18:42:50 schrieb Bram Moolenaar: > > > > I wrote: > > > > > Applying your git cleanup script after the conversion from hg to git > > > produces lots of these errors: > > > > > > fatal: ambiguous argument 'v7.2.434~4': unknown revision or path not in > > > the working tree. > > > Use '--' to separate paths from revisions, like this: > > > 'git [...] -- [...]' > > > > > > I'll have a look myself, but perhas you can guess what is wrong? > > > Or should these errors be ignored? > > These errors should not occur. > The reason for them is that the mentioned tag used in the Git cleanup > script cannot be found. In fact, the tags in the Git repo you pushed to > GitHub use the old naming scheme with dashes, i.e. v7-2-434 instead of > v7.2.434 > > It seems you did the conversion from a partially cleaned up HG > repository, where the step of tag renaming was missing. > > The online HG repo with applied cleanup script looks fine, it is the > same compared to my HG repo cleanup and includes the tag renaming. > > The rest of the Git cleanup script was successful. Only the step to > remove the 6 wrong commits, which required the missing tag, failed. > > > I let the script continue, ignoring the errors. Then I pushed the > > result to github. I got some errors, I think my sequence of commands is > > not quite right, probably some can be left out: > > > > % git remote add origin g...@github.com:vim/vim.git > > % git remote -v > > % git push --mirror > > % git push --set-upstream origin master > > % git push --tags > > % git push origin :origin/master > > Should be ok. Tried locally and it looked good, I only got an error with > the last command because the branch "origin/master" did not exist yet on > the remote repository and could not be deleted. > > > The result is now at https://github.com/vim/vim. It does have > > everything up to patch 7.4.827. Does it look OK? > > Not quite. Apart from the wrong tag naming there is also a wrong merge > order in the two merge commits (obtain them with "git log --merges"), > which already was the case with the direct Google Export. > > You said you use the Ubuntu package. I had a look: > http://packages.ubuntu.com/source/vivid/hg-fast-export > Even in the latest Ubuntu version 15.04, the package is from 2014-03-08, > despite having received changes upstream until October 2014. The merge > order problem has been fixed during that time (log: "do not sort merge > commit parents"). The same version is used on Debian unstable Sid. > > A bit disappointing that obviously an old distro package is used for the > Google Exporter. > > So you should use the latest version of hg-fast-export from > http://repo.or.cz/w/fast-export.git > and redo the conversion. > > It so happened that 3 days ago there were some new commits. I just > tested, they had no influence and the result is identical (equal object > SHA1 checksums). > > > I'll push the cleaned-up Mercurial repository to Google code next. > > That part appears to be OK now. > > Yes, looks fine. It's available now. I have removed the Ubuntu package for hg-fast-export and downloaded the individual files from repo.or.cz. The conversion now runs without any errors or warnings. The result is now available at https://github.com/vim/vim-tryout. Let me know if this is perfect, then I'll push to the vim/vim repository. And then we can continue from there. One thing that's different from the export: That one shows the author as "brammool", that is my GitHub user account. This gives me statistics etc. The locally converted repo doesn't have this. Perhaps this is a matter of changing the email address? Hmm, I can add my b...@vim.org address to my GitHub account. It didn't have an effect at the toplevel, but if I now open a commit it works. Perhaps it's just some caching. I do believe my commits will also use b...@vim.org. -- An indication you must be a manager: You can explain to somebody the difference between "re-engineering", "down-sizing", "right-sizing", and "firing people's asses". /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On 19-Aug-15, Bram Moolenaar wrote:
>
> Justin M. Keyes wrote:
>
> > On 8/18/15, Bram Moolenaar wrote:
> > >
> > > There were a couple of hiccups, but the repository has moved to GitHub
> > > now. It's in the destination place: https://github.com/vim/vim
> > >
> > > Now we need to do the git cleanup. I'll hold off until it looks OK,
> > > https://github.com/vim/vim-tryout is what it would look like.
> > > At least it doesn't have the old branches. Apparently the import
> > > resurrected what the Mercurial cleanup was supposed to remove.
> >
> > Why was the _mercurial_ tag format changed in the google code
> > repository? This breaks all URLs using the old tag format:
> >
> > https://code.google.com/p/vim/source/detail?r=v7-4-827
> >
> > Now the URL must be formatted like this:
> >
> > https://code.google.com/p/vim/source/detail?r=v7.4.827
> >
> > What is the purpose of VCS tags if they're going to be changed? It is
> > part of the VCS history. Only new tags should use the new format, not
> > the old tags.
>
> Yeah, it's not nice that old URLs stop working. Unfortunately you are
> too late with this remark, it already happened. We can't make both
> work, can we?
Untested.
Git allows multiple tags on a commit, and Mercurial seems to allow that
too (https://mercurial.selenic.com/wiki/Tag).
Markus, does it work if your script only adds the new tag, keeping the
old one?
Looking at hg-fast-export, it should have no problem picking up old and
new tags.
--- vim-hg-repo-cleanup-script.sh~ 2015-08-19 13:59:42.0 +0200
+++ vim-hg-repo-cleanup-script.sh 2015-08-19 14:00:48.0 +0200
@@ -164,7 +164,7 @@ for i in `hg tags --debug | tac | awk '/
REV=${i/*:/}
OLDTAG=${i/:*/}
NEWTAG=${OLDTAG//-/.}
-echo -e "$REV $NEWTAG\n$REV
$OLDTAG\n $OLDTAG" >> .hgtags
+echo "$REV $NEWTAG" >> .hgtags
done
hg commit -m"Rename tags to match the normal version notation"
--
Olaf Dabrunz (oda fctrace.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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Justin M. Keyes wrote: > On 8/18/15, Bram Moolenaar wrote: > > > > There were a couple of hiccups, but the repository has moved to GitHub > > now. It's in the destination place: https://github.com/vim/vim > > > > Now we need to do the git cleanup. I'll hold off until it looks OK, > > https://github.com/vim/vim-tryout is what it would look like. > > At least it doesn't have the old branches. Apparently the import > > resurrected what the Mercurial cleanup was supposed to remove. > > Why was the _mercurial_ tag format changed in the google code > repository? This breaks all URLs using the old tag format: > > https://code.google.com/p/vim/source/detail?r=v7-4-827 > > Now the URL must be formatted like this: > > https://code.google.com/p/vim/source/detail?r=v7.4.827 > > What is the purpose of VCS tags if they're going to be changed? It is > part of the VCS history. Only new tags should use the new format, not > the old tags. Yeah, it's not nice that old URLs stop working. Unfortunately you are too late with this remark, it already happened. We can't make both work, can we? -- A hamburger walks into a bar, and the bartender says: "I'm sorry, but we don't serve food here." /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: > Am Dienstag, 18. August 2015, 18:42:50 schrieb Bram Moolenaar: > > > > I wrote: > > > > > Applying your git cleanup script after the conversion from hg to git > > > produces lots of these errors: > > > > > > fatal: ambiguous argument 'v7.2.434~4': unknown revision or path not in > > > the working tree. > > > Use '--' to separate paths from revisions, like this: > > > 'git [...] -- [...]' > > > > > > I'll have a look myself, but perhas you can guess what is wrong? > > > Or should these errors be ignored? > > These errors should not occur. > The reason for them is that the mentioned tag used in the Git cleanup > script cannot be found. In fact, the tags in the Git repo you pushed to > GitHub use the old naming scheme with dashes, i.e. v7-2-434 instead of > v7.2.434 > > It seems you did the conversion from a partially cleaned up HG > repository, where the step of tag renaming was missing. Hmm, it's possible in all the tryouts I forgot to run the Mercurial cleanup. Or used the wrong Mercurial repo to convert from. I should delete old stuff. > The online HG repo with applied cleanup script looks fine, it is the > same compared to my HG repo cleanup and includes the tag renaming. OK, glad that worked. > The rest of the Git cleanup script was successful. Only the step to > remove the 6 wrong commits, which required the missing tag, failed. I'll redo this part tonight, using the cleaned up Mercurial repo, and push to the vim-tryout repo on github. That should give the same result as doing it "for real", but not risking damaging the vim repo. Although it seems with --mirror we can always overwrite it with a corrected one. > > I let the script continue, ignoring the errors. Then I pushed the > > result to github. I got some errors, I think my sequence of commands is > > not quite right, probably some can be left out: > > > > % git remote add origin g...@github.com:vim/vim.git > > % git remote -v > > % git push --mirror > > % git push --set-upstream origin master > > % git push --tags > > % git push origin :origin/master > > Should be ok. Tried locally and it looked good, I only got an error with > the last command because the branch "origin/master" did not exist yet on > the remote repository and could not be deleted. So I just leave out the last command? > > The result is now at https://github.com/vim/vim. It does have > > everything up to patch 7.4.827. Does it look OK? > > Not quite. Apart from the wrong tag naming there is also a wrong merge > order in the two merge commits (obtain them with "git log --merges"), > which already was the case with the direct Google Export. Yes, this is the result of the Google export. Or GitHub import from Google Code, as the conversion is actually done by GitHub. > You said you use the Ubuntu package. I had a look: > http://packages.ubuntu.com/source/vivid/hg-fast-export > Even in the latest Ubuntu version 15.04, the package is from 2014-03-08, > despite having received changes upstream until October 2014. The merge > order problem has been fixed during that time (log: "do not sort merge > commit parents"). The same version is used on Debian unstable Sid. > > A bit disappointing that obviously an old distro package is used for the > Google Exporter. > > So you should use the latest version of hg-fast-export from > http://repo.or.cz/w/fast-export.git > and redo the conversion. OK, sounds like we identified what's wrong in the sequence of commands. > It so happened that 3 days ago there were some new commits. I just > tested, they had no influence and the result is identical (equal object > SHA1 checksums). > > > I'll push the cleaned-up Mercurial repository to Google code next. > > That part appears to be OK now. > > Yes, looks fine. It's available now. OK. More tonight. -- ARTHUR: Charge! [They all charge with swords drawn towards the RABBIT. A tremendous twenty second fight with Peckinpahish shots and borrowing heavily also on the Kung Fu and karate-type films ensues, in which some four KNIGHTS are comprehensively killed.] ARTHUR: Run away! Run away! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://
Re: Repository cleanup (Was: Preparations for moving to github)
On 8/18/15, Bram Moolenaar wrote: > > There were a couple of hiccups, but the repository has moved to GitHub > now. It's in the destination place: https://github.com/vim/vim > > Now we need to do the git cleanup. I'll hold off until it looks OK, > https://github.com/vim/vim-tryout is what it would look like. > At least it doesn't have the old branches. Apparently the import > resurrected what the Mercurial cleanup was supposed to remove. Why was the _mercurial_ tag format changed in the google code repository? This breaks all URLs using the old tag format: https://code.google.com/p/vim/source/detail?r=v7-4-827 Now the URL must be formatted like this: https://code.google.com/p/vim/source/detail?r=v7.4.827 What is the purpose of VCS tags if they're going to be changed? It is part of the VCS history. Only new tags should use the new format, not the old tags. -- Justin M. Keyes -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On 18-Aug-15, Christian Brabandt wrote: > Here is a documentation update: > > Stay with mercurial > === > > A repository at bitbucket.org has been setup that mirrors the official Vim > source repository at https://github.com/vim/vim Minor nit-pick: "has been setup" -> "has been set up" http://grammarist.com/spelling/set-up-vs-setup -- Olaf Dabrunz (oda fctrace.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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
There were a couple of hiccups, but the repository has moved to GitHub now. It's in the destination place: https://github.com/vim/vim Now we need to do the git cleanup. I'll hold off until it looks OK, https://github.com/vim/vim-tryout is what it would look like. At least it doesn't have the old branches. Apparently the import resurrected what the Mercurial cleanup was supposed to remove. -- TIM: That is not an ordinary rabbit ... 'tis the most foul cruel and bad-tempered thing you ever set eyes on. ROBIN: You tit. I soiled my armour I was so scared! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Dienstag, 18. August 2015, 18:42:50 schrieb Bram Moolenaar: > > I wrote: > > > Applying your git cleanup script after the conversion from hg to git > > produces lots of these errors: > > > > fatal: ambiguous argument 'v7.2.434~4': unknown revision or path not in the > > working tree. > > Use '--' to separate paths from revisions, like this: > > 'git [...] -- [...]' > > > > I'll have a look myself, but perhas you can guess what is wrong? > > Or should these errors be ignored? These errors should not occur. The reason for them is that the mentioned tag used in the Git cleanup script cannot be found. In fact, the tags in the Git repo you pushed to GitHub use the old naming scheme with dashes, i.e. v7-2-434 instead of v7.2.434 It seems you did the conversion from a partially cleaned up HG repository, where the step of tag renaming was missing. The online HG repo with applied cleanup script looks fine, it is the same compared to my HG repo cleanup and includes the tag renaming. The rest of the Git cleanup script was successful. Only the step to remove the 6 wrong commits, which required the missing tag, failed. > I let the script continue, ignoring the errors. Then I pushed the > result to github. I got some errors, I think my sequence of commands is > not quite right, probably some can be left out: > > % git remote add origin g...@github.com:vim/vim.git > % git remote -v > % git push --mirror > % git push --set-upstream origin master > % git push --tags > % git push origin :origin/master Should be ok. Tried locally and it looked good, I only got an error with the last command because the branch "origin/master" did not exist yet on the remote repository and could not be deleted. > The result is now at https://github.com/vim/vim. It does have > everything up to patch 7.4.827. Does it look OK? Not quite. Apart from the wrong tag naming there is also a wrong merge order in the two merge commits (obtain them with "git log --merges"), which already was the case with the direct Google Export. You said you use the Ubuntu package. I had a look: http://packages.ubuntu.com/source/vivid/hg-fast-export Even in the latest Ubuntu version 15.04, the package is from 2014-03-08, despite having received changes upstream until October 2014. The merge order problem has been fixed during that time (log: "do not sort merge commit parents"). The same version is used on Debian unstable Sid. A bit disappointing that obviously an old distro package is used for the Google Exporter. So you should use the latest version of hg-fast-export from http://repo.or.cz/w/fast-export.git and redo the conversion. It so happened that 3 days ago there were some new commits. I just tested, they had no influence and the result is identical (equal object SHA1 checksums). > I'll push the cleaned-up Mercurial repository to Google code next. > That part appears to be OK now. Yes, looks fine. It's available now. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Christian Brabandt wrote: > On Di, 18 Aug 2015, Bram Moolenaar wrote: > > > Note: I have started doing things "for real". > > The cleaned up Mercurial repository has been pushed to Google code. > > I have resynced the bitbucket mirror. I will update the sync script > tomorrow, when the new github repository should be available. And once > it is there, I will switch on to sync the repository every 15 Minutes. OK, let me know if you spot something wrong. The project move to github ran into an error. But the GitHub staff is very responsive, let's see if they can fix it. > Here is a documentation update: Thanks! I'll integrate this later. -- If cars evolved at the same rate as computers have, they'd cost five euro, run for a year on a couple of liters of petrol, and explode once a day. /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Di, 18 Aug 2015, Bram Moolenaar wrote: > Note: I have started doing things "for real". > The cleaned up Mercurial repository has been pushed to Google code. I have resynced the bitbucket mirror. I will update the sync script tomorrow, when the new github repository should be available. And once it is there, I will switch on to sync the repository every 15 Minutes. Here is a documentation update: Stay with mercurial === A repository at bitbucket.org has been setup that mirrors the official Vim source repository at https://github.com/vim/vim To switch to the new mercurial repository, simply edit the file .hg/hgrc in the mercurial vim repository and change the following line [paths] default = https://code.google.com/p/vim/ to the new repository: [paths] default = https://bitbucket.org/vim-mirror/vim That's it. Run `hg pull -u` to fetch from the new mercurial repository and update your working copy. For developing patches, you can proceed as mentioned at http://www.vim.org/develop.php Best, Christian -- Die Menschen sind durch die unendlichen Bedingungen des Erscheinens dergestalt obruiert, dass sie das eine Urbedingende nicht gewahren können. -- Goethe, Maximen und Reflektionen, Nr. 850 -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Note: I have started doing things "for real". The cleaned up Mercurial repository has been pushed to Google code. I'll now start the export to github. We can redo this when needed. In preparation I've renamed the previously exported repo, which was overwritten with the cleaned up one, to vim-tryout. I'll now announce the Google code site is "frozen". Specifically, don't add or edit Issues there. -- TIM:Too late. ARTHUR: What? TIM:There he is! [They all turn, and see a large white RABBIT lollop a few yards out of the cave. Accompanied by terrifying chord and jarring metallic monster noise.] "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On 18 August 2015, Bram Moolenaar wrote: > > Lcd wrote: > > > On 18 August 2015, Bram Moolenaar wrote: > > [...] > > > For users who switch from Mercurial on Google Code to the Mercurial > > > mirror, there would be an extra commit that doesn't exist anywhere > > > else. I hope that will work. > > [...] > > > > Why not make the Bitbucket mirror at the same time as the Github > > migration? The commit with the annoying message only needs to exist > > on Google Code. There's no point in copying that particular commit to > > Bitbucket and undoing it immediately afterwards, right? > > Yes, if we get the timing right. If someone is too late, he will > already have gotten the extra commit from Google code. When switching > to the other Mercurial repository, which doesn't have this commit, what > happens? Hmm, right, it would no longer be possible to just switch the address in hgrc. Well, I suppose keeping the extra commit is harmless anyway. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
I wrote: > Applying your git cleanup script after the conversion from hg to git > produces lots of these errors: > > fatal: ambiguous argument 'v7.2.434~4': unknown revision or path not in the > working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > > I'll have a look myself, but perhas you can guess what is wrong? > Or should these errors be ignored? I let the script continue, ignoring the errors. Then I pushed the result to github. I got some errors, I think my sequence of commands is not quite right, probably some can be left out: % git remote add origin g...@github.com:vim/vim.git % git remote -v % git push --mirror % git push --set-upstream origin master % git push --tags % git push origin :origin/master The result is now at https://github.com/vim/vim. It does have everything up to patch 7.4.827. Does it look OK? I'll push the cleaned-up Mercurial repository to Google code next. That part appears to be OK now. -- Vi beats Emacs to death, and then again! http://linuxtoday.com/stories/5764.html /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Lcd wrote: > On 18 August 2015, Bram Moolenaar wrote: > [...] > > For users who switch from Mercurial on Google Code to the Mercurial > > mirror, there would be an extra commit that doesn't exist anywhere > > else. I hope that will work. > [...] > > Why not make the Bitbucket mirror at the same time as the Github > migration? The commit with the annoying message only needs to exist > on Google Code. There's no point in copying that particular commit to > Bitbucket and undoing it immediately afterwards, right? Yes, if we get the timing right. If someone is too late, he will already have gotten the extra commit from Google code. When switching to the other Mercurial repository, which doesn't have this commit, what happens? -- The war between Emacs and Vi is over. Vi has won with 3 to 1. http://m.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/030/3044/3044s1.html /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus - Applying your git cleanup script after the conversion from hg to git produces lots of these errors: fatal: ambiguous argument 'v7.2.434~4': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' I'll have a look myself, but perhas you can guess what is wrong? Or should these errors be ignored? -- TALL KNIGHT: Firstly. You must get us another shrubbery! OTHER KNIGHTS: More shrubberies! More shrubberies for the ex-Knights of Ni! ARTHUR:Not another shrubbery - "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On 18 August 2015, Bram Moolenaar wrote: [...] > For users who switch from Mercurial on Google Code to the Mercurial > mirror, there would be an extra commit that doesn't exist anywhere > else. I hope that will work. [...] Why not make the Bitbucket mirror at the same time as the Github migration? The commit with the annoying message only needs to exist on Google Code. There's no point in copying that particular commit to Bitbucket and undoing it immediately afterwards, right? /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Aw: Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: > > Wonderful! And just in time, I'm working on Vim today. > > Then staying up late was worth it :) And thanks for checking the plan. > > So, these are the steps to be taken: > > 1. Stop making changes: "freeze"; announce on Google code project page. > >Announce on the vim maillists. > > 2. Run ~/tmp/clean_repo.sh on the Mercurial repo. > > 3. Push to Google code. Google code will remain in this state for a week. > > 4. Delete the testing repositories on github. > >Put a note on the github site that it's under construction. > > 5. On Google code, use the export functionality to move to github. > >This will create the "Vim" repository there. > > > > This will take some time. While that's happening do this locally: > > > > 6. Change my scripts to use the new tag format: v7.4.999 > > 7. Commit a change in the Mercurial repo to break the build, pointing the > > user > >to github. Do NOT push this yet. > > 8. Convert the Mercurial repo to github. > > 9. Commit a change that undoes the build breakage. > > 10. Run the git cleanup script: ~/tmp/clean_git.sh > > In my opinion it would be a shame to start with such two workaround > commits in a repository just cleaned up. They will live there forever, > the workaround will only be used for the then old HG repository on > Google until the switch-off in January 2016. > > As far as I understood the procedure Christian uses for the HG mirror, > it doesn't matter at all whether these two commits exist in the Git > repository or not. It should be possible to apply the unbreak patch only > to the HG mirror. > > So I suggest to swap 7. and 8. and leave 9. for Christian. That's OK with me. So we have the git repository start just before the commit that changes the build. I've decided to not actually break it, it appears that an annoying message should be sufficient. For users who switch from Mercurial on Google Code to the Mercurial mirror, there would be an extra commit that doesn't exist anywhere else. I hope that will work. > > Wait for the move tool to finish, check that it looks OK, all issues have > > been > > moved. > > > > 11. Use git push --mirror to overwrite the repository at github with the > > cleaned up one. > > 12. "unfreeze", continue committing patches, editing issues, etc. on github > > 13. Tell everybody to start using github, add a message on Google code > > that the site is deprecated, any changes will be discarded. > > My patches will go to github only. > > 14. Push the change to the Mercurial repository that breaks the build. > > This must be done before August 25. > > 15. After checking that it works, set the Google code site to the > > "project moved" state. Mercurial keeps working still, but gets the > > older version, with the broken build. > > In case you didn't already have the idea: > In the broken build you might want to point to the HG mirror or to the > Vim site with documentation for switching. Yes, I started a page for that, it's not linked anywhere yet: http://www.vim.org/movetogithub.php > > Done! > > Looks good. > > > Note: steps 9 and 10 may be swapped. I think it's best to undo the > > build breakage first, so that it's immediately after the commit that > > breaks it. But I'm not 100% sure this doesn't cause a problem for the > > git cleanup. > > I guess it should not make a difference, but as I wrote, I'm not in > favor of this approach. -- TALL KNIGHT: We are now no longer the Knights Who Say Ni! ONE KNIGHT: Ni! OTHERS: Sh! ONE KNIGHT: (whispers) Sorry. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
I hope I don't brake the mail chain, I'm not at home at my mail client. > Wonderful! And just in time, I'm working on Vim today. Then staying up late was worth it :) > So, these are the steps to be taken: > 1. Stop making changes: "freeze"; announce on Google code project page. >Announce on the vim maillists. > 2. Run ~/tmp/clean_repo.sh on the Mercurial repo. > 3. Push to Google code. Google code will remain in this state for a week. > 4. Delete the testing repositories on github. >Put a note on the github site that it's under construction. > 5. On Google code, use the export functionality to move to github. >This will create the "Vim" repository there. > > This will take some time. While that's happening do this locally: > > 6. Change my scripts to use the new tag format: v7.4.999 > 7. Commit a change in the Mercurial repo to break the build, pointing the user >to github. Do NOT push this yet. > 8. Convert the Mercurial repo to github. > 9. Commit a change that undoes the build breakage. > 10. Run the git cleanup script: ~/tmp/clean_git.sh In my opinion it would be a shame to start with such two workaround commits in a repository just cleaned up. They will live there forever, the workaround will only be used for the then old HG repository on Google until the switch-off in January 2016. As far as I understood the procedure Christian uses for the HG mirror, it doesn't matter at all whether these two commits exist in the Git repository or not. It should be possible to apply the unbreak patch only to the HG mirror. So I suggest to swap 7. and 8. and leave 9. for Christian. > Wait for the move tool to finish, check that it looks OK, all issues have been > moved. > > 11. Use git push --mirror to overwrite the repository at github with the > cleaned up one. > 12. "unfreeze", continue committing patches, editing issues, etc. on github > 13. Tell everybody to start using github, add a message on Google code > that the site is deprecated, any changes will be discarded. > My patches will go to github only. > 14. Push the change to the Mercurial repository that breaks the build. > This must be done before August 25. > 15. After checking that it works, set the Google code site to the > "project moved" state. Mercurial keeps working still, but gets the > older version, with the broken build. In case you didn't already have the idea: In the broken build you might want to point to the HG mirror or to the Vim site with documentation for switching. > Done! Looks good. > Note: steps 9 and 10 may be swapped. I think it's best to undo the > build breakage first, so that it's immediately after the commit that > breaks it. But I'm not 100% sure this doesn't cause a problem for the > git cleanup. I guess it should not make a difference, but as I wrote, I'm not in favor of this approach. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: > Am Sonntag, 16. August 2015, 15:23:15 schrieb Bram Moolenaar: > > > > OK, if there is a chance you still find some improvements for the > > Mercurial cleanup, we better wait a bit before doing that. > > > > Once you have it all figured out, I hope you can send me the final > > scripts. I wouldn't want some small mistake spoil the fun. > > Here are the final two scripts for HG and Git cleanup. > The intermediate step (HG to Git conversion) you already figured out. > > The HG cleanup now contains the tag renaming as discussed. Do not forget > to adapt your scripts for the new tag naming scheme using dots instead > of dashes. > > I suggest to invoke each step in a copy (cp -a) of the particular base > repository so you can easily repeat it without having to go through the > whole chain. And for comparing the state before and after each step. Wonderful! And just in time, I'm working on Vim today. So, these are the steps to be taken: 1. Stop making changes: "freeze"; announce on Google code project page. Announce on the vim maillists. 2. Run ~/tmp/clean_repo.sh on the Mercurial repo. 3. Push to Google code. Google code will remain in this state for a week. 4. Delete the testing repositories on github. Put a note on the github site that it's under construction. 5. On Google code, use the export functionality to move to github. This will create the "Vim" repository there. This will take some time. While that's happening do this locally: 6. Change my scripts to use the new tag format: v7.4.999 7. Commit a change in the Mercurial repo to break the build, pointing the user to github. Do NOT push this yet. 8. Convert the Mercurial repo to github. 9. Commit a change that undoes the build breakage. 10. Run the git cleanup script: ~/tmp/clean_git.sh Wait for the move tool to finish, check that it looks OK, all issues have been moved. 11. Use git push --mirror to overwrite the repository at github with the cleaned up one. 12. "unfreeze", continue committing patches, editing issues, etc. on github 13. Tell everybody to start using github, add a message on Google code that the site is deprecated, any changes will be discarded. My patches will go to github only. 14. Push the change to the Mercurial repository that breaks the build. This must be done before August 25. 15. After checking that it works, set the Google code site to the "project moved" state. Mercurial keeps working still, but gets the older version, with the broken build. Done! Note: steps 9 and 10 may be swapped. I think it's best to undo the build breakage first, so that it's immediately after the commit that breaks it. But I'm not 100% sure this doesn't cause a problem for the git cleanup. If someone spots a problem, please report it soon, because I plan to start doing this today. -- ARTHUR: Ni! BEDEVERE: Nu! ARTHUR: No. Ni! More like this. "Ni"! BEDEVERE: Ni, ni, ni! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Sonntag, 16. August 2015, 15:23:15 schrieb Bram Moolenaar:
>
> OK, if there is a chance you still find some improvements for the
> Mercurial cleanup, we better wait a bit before doing that.
>
> Once you have it all figured out, I hope you can send me the final
> scripts. I wouldn't want some small mistake spoil the fun.
Here are the final two scripts for HG and Git cleanup.
The intermediate step (HG to Git conversion) you already figured out.
The HG cleanup now contains the tag renaming as discussed. Do not forget
to adapt your scripts for the new tag naming scheme using dots instead
of dashes.
I suggest to invoke each step in a copy (cp -a) of the particular base
repository so you can easily repeat it without having to go through the
whole chain. And for comparing the state before and after each step.
#!/bin/bash
# Vim HG repository cleanup
#
# Overview:
# - close stale branches
# - fix wrong tags
# - remove unused tags
# - add missing tags
# - rename tags: replace - by .
set -e
hg config extensions.rebase || { echo -e "Rebase extension has to be enabled in
~/.hgrc:\n[extensions]\nrebase =" && exit 1; }
# close stale branches, switch back to default branch afterwards
# This has the slightly bad visual side-effect of parallel development from the
# previous branch head up to the corresponding closing commit in "hg log
# --graph", but is the correct thing to do to avoid seemingly active branches
# showing up in "hg branches" output.
hg update -C vim
hg commit --close-branch -m"Close invalid branch 'vim'"
hg update -C vim72
hg commit --close-branch -m"Close unused branch 'vim72'"
hg update -C vim73
hg commit --close-branch -m"Close old branch 'vim73'"
hg update -C default
# remove unused branch lines
# However, since the network protocol works append-only, you cannot push it
# to the public repo. This would have to be done directly on the server via SSH
# or an admin interface.
# And still this change would have no effect when pulling from existing
# clones, it would have to be stripped there as well, so ignore this step.
#hg strip vim
#hg strip vim72
# find potentially wrong tags by checking whether the patch number had been
# added to src/version.c in that changeset
#for i in $(hg tags | grep -o "v7-.*-[^ ]*"); do hg diff -c $i src/version.c |
grep -q "^+$(echo $i | sed -e 's/v7-.*-0*//')," || echo $i; done
# result:
# v7-4-415
# v7-4b-000
# v7-3-523
# v7-3-143
# v7-2-446
# v7-2-443
# v7-2-442
# v7-2-441
# v7-2-440
# v7-2-439
# v7-2-438
# v7-2-437
# v7-2-436
# v7-2-232
# v7-2-176
# v7-2-167fix
# v7-2-168
# v7-2-082
# v7-2-080
# v7-2-000
# v7-2c-000
# v7-2b-000
# v7-2a-00
# v7-1-258
# v7-1-008
# v7-0-225
# determine the actually wrong tags after manual inspection
# v7-4-415
# v7-3-143
# v7-2-446
# v7-2-443
# v7-2-442
# v7-2-441
# v7-2-440
# v7-2-439
# v7-2-438
# v7-2-437
# v7-2-436
# v7-2-232
# v7-2-176
# v7-2-167fix
# v7-2-168
# v7-2-082
# v7-2-080
# v7-1-008
# v7-0-225
# fix the wrong tags
# Do not edit the .hgtags file manually, but rely on "hg tag" to do the right
# thing, see
# http://mercurial.selenic.com/wiki/Tag
# http://mercurial.selenic.com/wiki/TagDesign
hg tag -f --local rebasedest
hg tag -f -r 2ec8266fa254f9f90fd302df275d2813ae08a8e6 v7-0-225
hg tag -f -r 042fa969dab175d414d611425d8a61424bacf75f v7-1-008
hg tag -f -r 12cecc379574aba2231cbba54c4eaeef3432db69 v7-2-080
hg tag -f -r be7491f23e9d8818821de61d9ce53cb1cb1c7dc9 v7-2-082
hg tag -f -r ad41c6afaa7b0b512cd97dd07a93cc0504508227 v7-2-168
hg tag -f -r e8eeeff19eae568f4642cb9f368a1aec6c749a61 v7-2-176
hg tag -f -r 5bd06a91c65c06847fb0d618c71736d7c73e95d2 v7-2-232
hg tag -f -r e12b9d992389cc770eb72e16932313cd0905190f v7-2-436
hg tag -f -r ecb9c2b70b0f6e9918e75bf4e1ac887748a2313a v7-2-437
hg tag -f -r d44112feb8153ffaa6ab8ec6442c5c4af0951728 v7-2-438
hg tag -f -r ea7c2d89b76bf42eb0da3459e8813104d76bca02 v7-2-439
hg tag -f -r cd6e6876308e4e0fb621431646ebeec4b49a2504 v7-2-440
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
# Optionally squash all separate tag changing commits into one
# with a proper description
cat < logfile.txt
Fix wrong tags
v7-2-167fix has been renamed to v7-2-167 because the state in repository
matched version 7.2.167.
The others have been moved to the correct changeset.
EOF
hg rebase --dest rebasedest --source tip~19 --collapse --logfile logfile.txt
rm logfile.txt
# remove unused tag
hg tag -m"Remove unused tag from invalid line of history" --remove start
# add missing tags
hg tag -f --local rebasedest
hg tag -r f03c3fae0a99 v7-0-076
hg
Re: Repository cleanup (Was: Preparations for moving to github)
Am Montag, 17. August 2015, 14:49:51 schrieb Marius Gedminas: > On Fri, Aug 14, 2015 at 01:39:18AM +0200, Markus Heidelberg wrote: > > Am Donnerstag, 13. August 2015, 13:14:34 schrieb Bram Moolenaar: > > > You mentioned the size of the repository after "export to github" was > > > much larger than the one resulting from the local conversion. How do > > > you see that? > > > > Try this (using your 2nd test repo): > > > > $ git clone https://github.com/vim/vim.git > > [..] > > Receiving objects: 42% (22538/53119), 206.21 MiB | 622.00 KiB/s > > > > -> 200 MB already transferred and still 58% to do. I aborted then. > > > > It seems like GitHub optimizes the repository some day later or > > regularly because your first test repo (now at > > https://github.com/vim/vim-old-tryout) has a reasonable compact size: > > Receiving objects: 100% (52960/52960), 33.29 MiB | 657.00 KiB/s, done. > > > > $ du -sh vim-old-tryout/.git > > 36M .git > > > > But I remember my initial clone a few months ago was really big. > > > > Compare the size of .git/ with your locally converted Git repo, this > > must be huge (743 MB for me). > > It might be a manual process. > > I remember when git clone https://github.com/vim/vim produced a 700 meg .git. > I complained on Twitter and somebody from GitHub noticed and ran a > manual "git gc --aggressive" (or something like that) on the server side: > > - https://twitter.com/mgedmin/status/581131821796196353 > - https://twitter.com/vmg/status/581144886826672130 Thanks for the pointers. > If you're planning to do a new conversion, you may need to ask GitHub > admins to do the compaction by hand again. No, we will convert locally and do the necessary "repack" step, which is missing from the Google Exporter, ourselves. Markus -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: > > > Maybe you can comment on some other items from the old mail as well. > > > > Can you repeat the relevant questions? > > Oh, not that many remaining which needed clarification. New comments by > myself compared to the old mail after "MH": > > * Unify name and mail for author and commiter, see: > $ git shortlog --email -s > > These should all be the same person for the current history. > > MH: In the latest git commits the mail is Bram@... (uppercase B), so > I'd use this. I don't care too much. All of the commits are actually from me, right? That the mail address changes at some points, probably because of switching to some other system or script, isn't really relevant for someone looking at it. It's not like they have to find out who committed a change. > * Format commit messages to work properly with git commands for the log > summary, > e.g. "git shortlog" or "git log --oneline". The output of these commands is > ugly at the moment. > > That means adding a blank line after the first line and ideally using > a descriptive one-liner for the first line. This is the format > recommended for Git repositories. > > e.g. from this: > Patch 7.2.446 > Problem:Crash in GUI when closing the last window in a tabpage. > (ryo7000) > Solution: Remove the tabpage from the list before freeing the window. > > to this (from vim_mainline.git): > [7.2.446] Crash in GUI when closing the last window in a tabpage. > (ryo7000) > > Problem:Crash in GUI when closing the last window in a tabpage. > (ryo7000) > > Solution: Remove the tabpage from the list before freeing the window. > > Patch 7.2.446 > > There may be better conversions without duplicating the problem > description. > > MH: Probably we should discard this because it only makes sense if it > is continued in your scripts. I had tried different messages, and it's difficult to find one that works well. Just using the patch number is consistent at least, but doesn't give much information. Using the "Problem" line has the problem (eh) that it's truncated at some unpredictable place. Writing a short line, like we have it in the README file on the ftp server, would be an awful lot of work. > * Add the patch description for commits before 7.2.328 > Unfortunately these commit messages do not include the patch > description, this was from the conversion to HG. Has nothing to do > with migration to Git, but maybe the effort is worth it. > > MH: I have to see whether the effort is manageable. I think if someone wants to full history of patches, the ftp server is more useful. After all, in the early days the patches were the main thing, the repository just following that. And before that there was no repository. It's unlikely that someone needs to look back to before 7.4. So let's just have the patches on 7.4 look good. We are getting closer to August 25, so let's try to get this done this week. -- Life is a gift, living is an art. (Bram Moolenaar) /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Fri, Aug 14, 2015 at 01:39:18AM +0200, Markus Heidelberg wrote: > Am Donnerstag, 13. August 2015, 13:14:34 schrieb Bram Moolenaar: > > You mentioned the size of the repository after "export to github" was > > much larger than the one resulting from the local conversion. How do > > you see that? > > Try this (using your 2nd test repo): > > $ git clone https://github.com/vim/vim.git > [..] > Receiving objects: 42% (22538/53119), 206.21 MiB | 622.00 KiB/s > > -> 200 MB already transferred and still 58% to do. I aborted then. > > It seems like GitHub optimizes the repository some day later or > regularly because your first test repo (now at > https://github.com/vim/vim-old-tryout) has a reasonable compact size: > Receiving objects: 100% (52960/52960), 33.29 MiB | 657.00 KiB/s, done. > > $ du -sh vim-old-tryout/.git > 36M .git > > But I remember my initial clone a few months ago was really big. > > Compare the size of .git/ with your locally converted Git repo, this > must be huge (743 MB for me). It might be a manual process. I remember when git clone https://github.com/vim/vim produced a 700 meg .git. I complained on Twitter and somebody from GitHub noticed and ran a manual "git gc --aggressive" (or something like that) on the server side: - https://twitter.com/mgedmin/status/581131821796196353 - https://twitter.com/vmg/status/581144886826672130 If you're planning to do a new conversion, you may need to ask GitHub admins to do the compaction by hand again. Marius Gedminas -- If the meanings of "true" and "false" were switched, then this sentence wouldn't be false. -- Douglas Hofstadter -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: Repository cleanup (Was: Preparations for moving to github)
Am Sonntag, 16. August 2015, 15:23:15 schrieb Bram Moolenaar: > > Markus Heidelberg wrote: > > > > 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: > > OK, if there is a chance you still find some improvements for the > Mercurial cleanup, we better wait a bit before doing that. > > Once you have it all figured out, I hope you can send me the final > scripts. I wouldn't want some small mistake spoil the fun. OK. > > 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. > > I do like the dot instead of the dash. It only got there because in the > past it wasn't allowed to have two dots. Perhaps that dates back from > the SVN days? > > Now that everybody has to switch their setup anyway, might as well do > this too. Once we have the switch done we will avoid more changes that > breaks people's habits. > > > Maybe you can comment on some other items from the old mail as well. > > Can you repeat the relevant questions? Oh, not that many remaining which needed clarification. New comments by myself compared to the old mail after "MH": * Unify name and mail for author and commiter, see: $ git shortlog --email -s These should all be the same person for the current history. MH: In the latest git commits the mail is Bram@... (uppercase B), so I'd use this. * Format commit messages to work properly with git commands for the log summary, e.g. "git shortlog" or "git log --oneline". The output of these commands is ugly at the moment. That means adding a blank line after the first line and ideally using a descriptive one-liner for the first line. This is the format recommended for Git repositories. e.g. from this: Patch 7.2.446 Problem:Crash in GUI when closing the last window in a tabpage. (ryo7000) Solution: Remove the tabpage from the list before freeing the window. to this (from vim_mainline.git): [7.2.446] Crash in GUI when closing the last window in a tabpage. (ryo7000) Problem:Crash in GUI when closing the last window in a tabpage. (ryo7000) Solution: Remove the tabpage from the list before freeing the window. Patch 7.2.446 There may be better conversions without duplicating the problem description. MH: Probably we should discard this because it only makes sense if it is continued in your scripts. * Add the patch description for commits before 7.2.328 Unfortunately these commit messages do not include the patch description, this was from the conversion to HG. Has nothing to do with migration to Git, but maybe the effort is worth it. MH: I have to see whether the effort is manageable. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: > > > 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. OK. So we can still chose between using the export from Google code and building on top of the resulting github repo, or doing the conversion locally and use --mirror to have it replace the github repo. I suppose this depends on how we do the patch on Mercurial to break the build, which should only be pushed after the conversion to github is fully successful. I'll await your suggestions. > > 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: OK, if there is a chance you still find some improvements for the Mercurial cleanup, we better wait a bit before doing that. Once you have it all figured out, I hope you can send me the final scripts. I wouldn't want some small mistake spoil the fun. > 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. I do like the dot instead of the dash. It only got there because in the past it wasn't allowed to have two dots. Perhaps that dates back from the SVN days? Now that everybody has to switch their setup anyway, might as well do this too. Once we have the switch done we will avoid more changes that breaks people's habits. > Maybe you can comment on some other items from the old mail as well. Can you repeat the relevant questions? -- Proofread carefully to see if you any words out. /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On So, 16 Aug 2015, Markus Heidelberg wrote: > Am Freitag, 14. August 2015, 09:42:34 schrieb Christian Brabandt: > > On Fr, 14 Aug 2015, Markus Heidelberg wrote: > > > > > I'd also prefer to just removing the .hgignore from the history and > > > replacing it with .gitignore. What would that mean for the HG mirror, > > > Christian? > > > > Hm, I don't know. I guess I can keep it checked in and let git ignore > > it. > > I guess you meant "let hg ignore it", didn't you? > But you'd want to have a .hgignore in your mirror. No I meant git. I have one working tree, which is a mirror of the git repository and at the same time, I am using this working tree for mercurial clone. What I then do is run a script periodically, that updates the git clone and for each (git) commit, apply this commit to mercurial as well and push the change. So if I re-add the .hgignore file, I have to tell git to ignore that file using .git/info/exclude (which I already use for ignoring the .hg directory). Best, Christian -- Der Krieg ist zu langsam für das Medium Fernsehen. -- Peter Slotterdijk -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
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
Re: Repository cleanup (Was: Preparations for moving to github)
Am Freitag, 14. August 2015, 09:42:34 schrieb Christian Brabandt: > Hi Markus! > > On Fr, 14 Aug 2015, Markus Heidelberg wrote: > > > I'd also prefer to just removing the .hgignore from the history and > > replacing it with .gitignore. What would that mean for the HG mirror, > > Christian? > > Hm, I don't know. I guess I can keep it checked in and let git ignore > it. I guess you meant "let hg ignore it", didn't you? But you'd want to have a .hgignore in your mirror. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Matthew Woehlke wrote: > On 2015-08-14 14:38, Bram Moolenaar wrote: > > 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. > > As far as non-git content (e.g. issues, pull requests), that may be true. > > To empty out the git bits of a repository: > > $ git checkout --orphan empty > $ git checkout master > $ git reset --hard empty > $ git branch -d empty > $ git push --force origin master > ...delete all other branches and tags... Thanks, but that looks like another example of how complicated git is... > The old objects will still be reachable for a while until garbage > collected, but they'll go away eventually. > > If you have the new history ready to go, you can just force-push that > over the old branches/tags and skip the emptying step (just remember to > delete anything you don't overwrite). The "git push --mirror" command might work better? We just need to overwrite the repository with what I have locally, dropping everything that I don't have locally. -- Mental Floss prevents moral decay! /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
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. > 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. 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? -- There are 10 kinds of people: Those who understand binary and those who don't. /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Freitag, 14. August 2015, 20:38:49 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. 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. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On 2015-08-14 14:38, Bram Moolenaar wrote: > 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. As far as non-git content (e.g. issues, pull requests), that may be true. To empty out the git bits of a repository: $ git checkout --orphan empty $ git checkout master $ git reset --hard empty $ git branch -d empty $ git push --force origin master ...delete all other branches and tags... The old objects will still be reachable for a while until garbage collected, but they'll go away eventually. If you have the new history ready to go, you can just force-push that over the old branches/tags and skip the emptying step (just remember to delete anything you don't overwrite). -- Matthew -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
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. 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? -- If your life is a hard drive, Christ can be your backup. /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Freitag, 14. August 2015, 15:05:41 schrieb Bram Moolenaar: > > Markus Heidelberg wrote: > > > Am Freitag, 14. August 2015, 01:39:18 schrieb Markus Heidelberg: > > > Am Donnerstag, 13. August 2015, 13:14:34 schrieb Bram Moolenaar: > > > > > > > > Markus Heidelberg wrote: > > > > > > > > [...] > > > > > > > > > > > 2. Conversion from HG to Git > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > Exactly! > > > > > > > > OK. So that are the best commands to do this conversion? > > > > > > Instead of "wipe the git repository" say "remove and create an empty git > > > repository" to be sure no stale stuff is left. But I guess you already > > > did this for your 2nd test repo. > > > > 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. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: > > > OK, then I would document a procedure for local HG to Git conversion and > > > create a script for Git repository cleanup. > > > > I did: > > > > % mkdir vim-git > > % cd vim-git > > % git init > > % hg-fast-export -r ../hg-vim74-clean > > On Arch Linux I had to set PYTHON=python2 for this command because the > default "python" is a symbolic link to python3. > > > % git checkout > > And then, as written in my previous mail, additionally: > > % git repack -a -d -f > % git gc OK. > I guess you got the hg-fast-export from one of these locations? > http://repo.or.cz/w/fast-export.git > https://github.com/frej/fast-export On Ubuntu it's a package that can be installed. > > Looks like it worked. I have replaced the "vim" repository on github > > with the cleaned up and locally converted repository. > > Please have a look: https://github.com/vim/vim > > I aborted the clone, despite not having to wait too long for it to > complete, but maybe you can create a new repo with the packfile > optimization applied. > From a quick look online, it seems fine. > > I saw you added the .gitignore already in the HG repo. I rather thought > of creating it as part of the cleanup based on .hgignore, then for the > whole history since addition of .hgignore. However, this can still be > done. I thought the .gitignore is useful anyway. It was only sitting in the git repo so far, and to avoid the first version of that being "broken" I thought it would be good to include now. > I'd also prefer to just removing the .hgignore from the history and > replacing it with .gitignore. What would that mean for the HG mirror, > Christian? I'm not sure what happens when mirrorring the git repo to Mercurial. If it converts the .gitignore to .hgignore an existing .hgignore might be a problem maybe? > > I have commited one new patch on top of it to check if that works. > > It looks OK, but I got a long list of messages like this: > > > > ... > > * [new tag] v7-4-823 -> v7-4-823 > > * [new tag] v7-4-824 -> v7-4-824 > > * [new tag] v7-4-825 -> v7-4-825 > > * [new tag] v7-4a -> v7-4a > > * [new tag] v7-4a-001 -> v7-4a-001 > > * [new tag] v7-4a-002 -> v7-4a-002 > > * [new tag] v7-4a-003 -> v7-4a-003 > > ... > > * [new tag] v7-4b-019 -> v7-4b-019 > > * [new tag] v7-4b-020 -> v7-4b-020 > > * [new tag] v7-4b-021 -> v7-4b-021 > > * [new tag] v7-4b-022 -> v7-4b-022 > > These messages occur for all the tags that have just been pushed. > > > Perhaps the original push to github should have been followed by "push > > --tags" ? Not sure if it makes any difference doing this after another > > commit+push. > > For the repository it doesn't make a difference if you forgot to push > the tags and do it later after unrelated commits. These are all > lightweight tags, just labels/pointers to a specific commit and not tied > to the history tree (DAG) at all. > The users would receive the missing tags with the next "git fetch". OK, so doing it earlier just makes it nicer. > > Please let me know if this looks OK. If yes then I'll do it for real > > this weekend. > > What do you mean with real? Only publishing the HG cleanup? > Because for the Git cleanup I have to prepare the script first. OK, I'll have to wait for that then. With "for real" I mean that we tell everybody to switch to the new repository and we stop updating the old one on Google code. -- FATHER:You only killed the bride's father - that's all - LAUNCELOT: Oh dear, I didn't really mean to... FATHER:Didn't mean to? You put your sword right through his head! LAUNCELOT: Gosh - Is he all right? "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: > Am Freitag, 14. August 2015, 01:39:18 schrieb Markus Heidelberg: > > Am Donnerstag, 13. August 2015, 13:14:34 schrieb Bram Moolenaar: > > > > > > Markus Heidelberg wrote: > > > > > > [...] > > > > > > > > > 2. Conversion from HG to Git > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > Exactly! > > > > > > OK. So that are the best commands to do this conversion? > > > > Instead of "wipe the git repository" say "remove and create an empty git > > repository" to be sure no stale stuff is left. But I guess you already > > did this for your 2nd test repo. > > 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. -- LAUNCELOT: I am, sir. I am a Knight of King Arthur. FATHER:'Mm ... very nice castle, Camelot ... very good pig country "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Hi Markus! On Fr, 14 Aug 2015, Markus Heidelberg wrote: > I'd also prefer to just removing the .hgignore from the history and > replacing it with .gitignore. What would that mean for the HG mirror, > Christian? Hm, I don't know. I guess I can keep it checked in and let git ignore it. Best, Christian -- Frau Meier will ihrer Nachbarin zeigen, wie toll ihr Sohn schon rechnen kann: F. M.: "Fritz, was ist drei mal vier?" Fritz: "zehn?" F. M.: "Sehen sie, nur um eins verrechnet!" -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Freitag, 14. August 2015, 01:39:18 schrieb Markus Heidelberg: > Am Donnerstag, 13. August 2015, 13:14:34 schrieb Bram Moolenaar: > > > > Markus Heidelberg wrote: > > > > [...] > > > > > > > 2. Conversion from HG to Git > > > > > > > > > > > > > > > > > > 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. > > > > > > Exactly! > > > > OK. So that are the best commands to do this conversion? > > Instead of "wipe the git repository" say "remove and create an empty git > repository" to be sure no stale stuff is left. But I guess you already > did this for your 2nd test repo. 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. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Donnerstag, 13. August 2015, 23:01:07 schrieb Bram Moolenaar: > > Markus Heidelberg wrote: > > > OK, then I would document a procedure for local HG to Git conversion and > > create a script for Git repository cleanup. > > I did: > > % mkdir vim-git > % cd vim-git > % git init > % hg-fast-export -r ../hg-vim74-clean On Arch Linux I had to set PYTHON=python2 for this command because the default "python" is a symbolic link to python3. > % git checkout And then, as written in my previous mail, additionally: % git repack -a -d -f % git gc I guess you got the hg-fast-export from one of these locations? http://repo.or.cz/w/fast-export.git https://github.com/frej/fast-export > Looks like it worked. I have replaced the "vim" repository on github > with the cleaned up and locally converted repository. > Please have a look: https://github.com/vim/vim I aborted the clone, despite not having to wait too long for it to complete, but maybe you can create a new repo with the packfile optimization applied. >From a quick look online, it seems fine. I saw you added the .gitignore already in the HG repo. I rather thought of creating it as part of the cleanup based on .hgignore, then for the whole history since addition of .hgignore. However, this can still be done. I'd also prefer to just removing the .hgignore from the history and replacing it with .gitignore. What would that mean for the HG mirror, Christian? > I have commited one new patch on top of it to check if that works. > It looks OK, but I got a long list of messages like this: > > ... > * [new tag] v7-4-823 -> v7-4-823 > * [new tag] v7-4-824 -> v7-4-824 > * [new tag] v7-4-825 -> v7-4-825 > * [new tag] v7-4a -> v7-4a > * [new tag] v7-4a-001 -> v7-4a-001 > * [new tag] v7-4a-002 -> v7-4a-002 > * [new tag] v7-4a-003 -> v7-4a-003 > ... > * [new tag] v7-4b-019 -> v7-4b-019 > * [new tag] v7-4b-020 -> v7-4b-020 > * [new tag] v7-4b-021 -> v7-4b-021 > * [new tag] v7-4b-022 -> v7-4b-022 These messages occur for all the tags that have just been pushed. > Perhaps the original push to github should have been followed by "push > --tags" ? Not sure if it makes any difference doing this after another > commit+push. For the repository it doesn't make a difference if you forgot to push the tags and do it later after unrelated commits. These are all lightweight tags, just labels/pointers to a specific commit and not tied to the history tree (DAG) at all. The users would receive the missing tags with the next "git fetch". > Please let me know if this looks OK. If yes then I'll do it for real > this weekend. What do you mean with real? Only publishing the HG cleanup? Because for the Git cleanup I have to prepare the script first. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Donnerstag, 13. August 2015, 13:14:34 schrieb Bram Moolenaar: > > Markus Heidelberg wrote: > > [...] > > > > > 2. Conversion from HG to Git > > > > > > > > > > > > > > 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. > > > > Exactly! > > OK. So that are the best commands to do this conversion? Instead of "wipe the git repository" say "remove and create an empty git repository" to be sure no stale stuff is left. But I guess you already did this for your 2nd test repo. Also the Git cleanup has to be added as last step. > I suppose I > can try this out now, since the github repository is for testing only. > > You mentioned the size of the repository after "export to github" was > much larger than the one resulting from the local conversion. How do > you see that? Try this (using your 2nd test repo): $ git clone https://github.com/vim/vim.git [..] Receiving objects: 42% (22538/53119), 206.21 MiB | 622.00 KiB/s -> 200 MB already transferred and still 58% to do. I aborted then. It seems like GitHub optimizes the repository some day later or regularly because your first test repo (now at https://github.com/vim/vim-old-tryout) has a reasonable compact size: Receiving objects: 100% (52960/52960), 33.29 MiB | 657.00 KiB/s, done. $ du -sh vim-old-tryout/.git 36M .git But I remember my initial clone a few months ago was really big. Compare the size of .git/ with your locally converted Git repo, this must be huge (743 MB for me). And if you clone this big repository and do not repack yourself, you have a great loss of performance, try e.g. "git log --graph". The difference does not come from the conversion script done locally, but from the missing packfile optimization, see that section in git-fast-import(1), which recommends this: $ git repack -a -d -f And then for your local clone (this will not have a positive effect for the published repo): $ git gc > > > > 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. > > > > OK, then I would document a procedure for local HG to Git conversion and > > create a script for Git repository cleanup. > > Can you give me that script? I could give it a try. I hope to get the cleanup script done during this weekend. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: > OK, then I would document a procedure for local HG to Git conversion and > create a script for Git repository cleanup. I did: % mkdir vim-git % cd vim-git % git init % hg-fast-export -r ../hg-vim74-clean % git checkout Looks like it worked. I have replaced the "vim" repository on github with the cleaned up and locally converted repository. Please have a look: https://github.com/vim/vim I have commited one new patch on top of it to check if that works. It looks OK, but I got a long list of messages like this: ... * [new tag] v7-4-823 -> v7-4-823 * [new tag] v7-4-824 -> v7-4-824 * [new tag] v7-4-825 -> v7-4-825 * [new tag] v7-4a -> v7-4a * [new tag] v7-4a-001 -> v7-4a-001 * [new tag] v7-4a-002 -> v7-4a-002 * [new tag] v7-4a-003 -> v7-4a-003 ... * [new tag] v7-4b-019 -> v7-4b-019 * [new tag] v7-4b-020 -> v7-4b-020 * [new tag] v7-4b-021 -> v7-4b-021 * [new tag] v7-4b-022 -> v7-4b-022 Perhaps the original push to github should have been followed by "push --tags" ? Not sure if it makes any difference doing this after another commit+push. Please let me know if this looks OK. If yes then I'll do it for real this weekend. -- Trees moving back and forth is what makes the wind blow. /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Markus Heidelberg wrote: [...] > > > 2. Conversion from HG to Git > > > > > > > > > > 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. > > Exactly! OK. So that are the best commands to do this conversion? I suppose I can try this out now, since the github repository is for testing only. You mentioned the size of the repository after "export to github" was much larger than the one resulting from the local conversion. How do you see that? > > > 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. > > OK, then I would document a procedure for local HG to Git conversion and > create a script for Git repository cleanup. Can you give me that script? I could give it a try. Actually, what I can do for testing is run the cleanup script for Mercurial, without pushing the changes back to Google code. Then run the local conversion script and do push the result to github. Then we should see exactly what we would get eventually, while not touching what is currently the official repository. Sounds like a safe and useful exercise. -- No letters of the alphabet were harmed in the creation of this message. /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Am Mittwoch, 12. August 2015, 23:20:21 schrieb Bram Moolenaar: > > Markus Heidelberg wrote: > > > 1. Cleanup in the HG repository > > *** > > > > 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 = Yes, it is enabled. > > 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. Yes, some kind of simulation for the public push later. Pushing from vim-hg-copy (if having executed the script there or after having pushed from vim-hg-copycloned to it) would push to Google. You can easily see the push destination in file .hg/hgrc to avoid the fear of an undesired public push. > As I asked on Christian's message: We can do this even before exporting > to github, right? Yes. > > 2. Conversion from HG to Git > > > > > > 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. Exactly! > > 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. OK, then I would document a procedure for local HG to Git conversion and create a script for Git repository cleanup. > > But the script won't mess up anything in the first place. > > Fingers crossed! :) -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Christian Brabandt wrote: > On Sa, 08 Aug 2015, Bram Moolenaar wrote: > > > 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. > > Since Markus has already provided the work and provided 2 versions of > the mercurial clean up script, I think it is safe to use. Just make > sure, to enable the rebase extension before running the script. I attach > the version, I used last (basically the patched version that Markus > provided last time). > > To be really safe, you could use a separate checkout and only push back, > if no error happened. This way, you won't mess up your normal working > copy. > > And after all, it's a VCS, so if something gets messed up, we can > revert, can't we? Not once committed to the server... So, to make sure we get this right, this script can be executed on a clean clone of the current Mercurial repository, and, if everything goes well, commited and pushed back to Google code. That is, it can be done before doing the export to github. Right? So, I could actually run it any day. -- BLACK KNIGHT: I move for no man. ARTHUR:So be it! [hah] [parry thrust] [ARTHUR chops the BLACK KNIGHT's left arm off] ARTHUR:Now stand aside, worthy adversary. BLACK KNIGHT: 'Tis but a scratch. The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
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 > > >
Re: Repository cleanup (Was: Preparations for moving to github)
Am Mittwoch, 12. August 2015, 08:50:55 schrieb Nazri Ramliy:
> On Wed, Aug 12, 2015 at 6:51 AM, Markus Heidelberg > #!/bin/sh
> > # Vim HG repository cleanup
> >
> > hg config extensions.rebase || (echo -e "Rebase extension has to be enabled
> > in ~/.hgrc:\n[extensions]\nrebase =" && exit 1)
>
> The "exit 1" above won't exit the shell script - it exits only the
> subshell. Perhaps you meant to use braces instead of parenthesis?:
>
> hg config extensions.rebase || { echo -e "Rebase extension has to
> be enabled in ~/.hgrc:\n[extensions]\nrebase =" && exit 1; }
Oh, I thought I tested this addition with context, but it seems I just
tested this single line on the command line. I guess this syntax came
from some Windows Batch spook in my head.
Markus
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Wed, Aug 12, 2015 at 6:51 AM, Markus Heidelberg > #!/bin/sh
> # Vim HG repository cleanup
>
> hg config extensions.rebase || (echo -e "Rebase extension has to be enabled
> in ~/.hgrc:\n[extensions]\nrebase =" && exit 1)
The "exit 1" above won't exit the shell script - it exits only the
subshell. Perhaps you meant to use braces instead of parenthesis?:
hg config extensions.rebase || { echo -e "Rebase extension has to
be enabled in ~/.hgrc:\n[extensions]\nrebase =" && exit 1; }
nazri
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Hi Bram, 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. 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. 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 # 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? [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. 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. 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. 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. B
Re: Repository cleanup (Was: Preparations for moving to github)
On Sa, 08 Aug 2015, Bram Moolenaar wrote: > 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. Since Markus has already provided the work and provided 2 versions of the mercurial clean up script, I think it is safe to use. Just make sure, to enable the rebase extension before running the script. I attach the version, I used last (basically the patched version that Markus provided last time). To be really safe, you could use a separate checkout and only push back, if no error happened. This way, you won't mess up your normal working copy. And after all, it's a VCS, so if something gets messed up, we can revert, can't we? Best, Christian -- Man glaubt gar nicht, wie schwer es oft ist, eine Tat in einen Gedanken umzusetzen. -- Emil Gött -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. clean_repo.sh Description: Bourne shell script
Re: Repository cleanup (Was: Preparations for moving to github)
I wrote: > 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. > > 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. > > 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. Looks like Markus is not responding. Anyone else who would like to take this on? We don't have much time left. -- ARTHUR: I did say sorry about the `old woman,' but from the behind you looked-- DENNIS: What I object to is you automatically treat me like an inferior! ARTHUR: Well, I AM king... The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
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. 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. 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. -- CUSTOMER: You're not fooling anyone y'know. Look, isn't there something you can do? DEAD PERSON: I feel happy... I feel happy. [whop] CUSTOMER: Ah, thanks very much. MORTICIAN:Not at all. See you on Thursday. CUSTOMER: Right. The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On 4/16/2015 1:33 PM, Nikolay Pavlov wrote: More powerful?! Try to add phases/changeset obsolescense/branches/etc to git. The point is that this “sharper knife” has an architecture that prevents adding feature to the core. You can do almost anything with the core using plugins for mercurial, but maximum thing you can do with git There's an interesting article I ran into earlier today from facebook develop https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ about how they switched from git to mercurial because they needed to work on their source control system to better scale. Bottom line Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
2015-04-16 9:36 GMT+03:00 Roland Eggner :
> On 2015-04-14 Tuesday at 20:00 +0300 Nikolay Pavlov wrote:
>> 2015-04-14 17:37 GMT+03:00 Roland Eggner :
>> > @Bram, @Christian, @all
>> > ───
>> > During some 10 years of almost daily usage of mercurial I have learned, I
>> > can
>> > usefully apply the philosophy, which Bram has provided in his book „Seven
>> > habits
>> > of effective text editing“:
>> > • Usage of a version management system will _save_ workload rather than
>> > to
>> >add workload, as soon as I switch from “insane” to “sane” thinking
>> > patterns.
>> > • Examples for “insane” thinking patterns are:
>> >How can I undo mercurial commands?
>> >How can I edit the repository?
>> >How can I work on a remote repository?
>> > • Examples for “sane” thinking and usage patterns are:
>> >Whenever I am not absolutely sure about the consequences of my next
>> > action,
>> >I run “hg clone …” firstly. On decent file systems this is cheap
>> > because
>> >only file names are copied, not file contents. Dependent on the outcome
>> >I drop the older or the newer repository later -- this way I have no
>> > need for
>> >any kind of undo actions and can relax.
>> >Every “hg pull” is followed by a “hg clone” or something equivalent,
>> > local
>> >repositories used for pulling are used for nothing else -- this way in
>> > the
>> >event of a failed merge or a failed “fast forward” I can just drop the
>> >concerning repository clone and reuse another local clone.
>> >For development as a basic principle I prefer local repositories.
>> > Apart from
>> >rare emergency cases, I use remote repositories for publishing and
>> > nothing
>> >else.
>> >
>> > For the currently discussed use case of Christian this means:
>> > • I would consider running the script remotely _only_ in the case of
>> >full-fledged SSH access and after at least one remotely executed “hg
>> > clone”.
>> > • In any other case and assuming network access without WLAN shortcomings,
>> >I would pull, clone locally at least once, run the script locally,
>> > check the
>> >result, if it satisfies then delete the remote repository and recreate
>> > it by
>> >pushing (deletion is required in this case because pushing allows only
>> >appending).
>> >
>> > For _new_ projects I use git rather than mercurial since approximately
>> > two
>> > years. Some of the reasons are:
>> > • git is better documented: just compare
>> >http://git-htmldocs.googlecode.com/git/git.html
>> >http://mercurial.selenic.com/wiki/ManPages
>>
>> You need to compare `hg help {command}` and `git help {command}`. `git
>> help {command}` redirects to `man git-{command}`, `hg help {command}`
>> uses docstrings and command definitions. They both have a reason to
>> provide documentation the way they do it:
>>
>> - Using `man` is simpler and it assumes that software (package manager
>> mainly) used to install git addons is able to install man pages.
>> - Using docstrings is more pythonic and `--editable` installs of
>> mercurial extensions will for sure *not* provide man pages. This
>> variant is more convenient for the extension developer.
>>
>> I can also say that while git is better documented, its documentation
>> is *worse*. When I look at `hg help something` I usually understand
>> immediately what I need to do. When I look at `git help something` I
>> need to parse a lot of currently useless text, sometimes just to find
>> out that I picked help for the wrong command.
>
> I prefer the html-documentation, it allows more convenient jumping between
> documents.
>
> E.g. “git help log” and “git help diff” are huge man pages, yes, but this is
> easily solved: I use the pager less, enter a perl search expression and
> libpcre
> does the parsing for me.
This only works as long as the search succeeds. If it does not you
have no way to know whether it does not succeed because functionality
is missing (at least from this command) or because man page authors
use different wording other then reading the whole documentation.
>
>
>> > • In my experience git was the very first tool with complete and flawless
>> >Unicode support -- even nowadays only few can compete in this concern
>> >(perl-5.12+, zsh-5.0+). This stays in contrast to mercurial: “hg diff
>> > …”
>> >occasionally outputs invalid Unicode characters, because trimming of the
>> >function name field ignores boundaries of multibyte characters -- this
>> > is
>> >even noted in the mercurial repository since several years, and there
>> > seems
>> >to be no intention to fix the bug. I have discussed two other examples
>> > of --
>> >in my subjective view -- odd design decisions of mercurial with the
>> >developers; the patches I offered have been rejected; this can be
>> > found in
>> >mercurial mailing list archives. More examples on request.
>>
>>
Re: Repository cleanup (Was: Preparations for moving to github)
On 2015-04-14 Tuesday at 20:00 +0300 Nikolay Pavlov wrote:
> 2015-04-14 17:37 GMT+03:00 Roland Eggner :
> > @Bram, @Christian, @all
> > ───
> > During some 10 years of almost daily usage of mercurial I have learned, I
> > can
> > usefully apply the philosophy, which Bram has provided in his book „Seven
> > habits
> > of effective text editing“:
> > • Usage of a version management system will _save_ workload rather than
> > to
> >add workload, as soon as I switch from “insane” to “sane” thinking
> > patterns.
> > • Examples for “insane” thinking patterns are:
> >How can I undo mercurial commands?
> >How can I edit the repository?
> >How can I work on a remote repository?
> > • Examples for “sane” thinking and usage patterns are:
> >Whenever I am not absolutely sure about the consequences of my next
> > action,
> >I run “hg clone …” firstly. On decent file systems this is cheap because
> >only file names are copied, not file contents. Dependent on the outcome
> >I drop the older or the newer repository later -- this way I have no
> > need for
> >any kind of undo actions and can relax.
> >Every “hg pull” is followed by a “hg clone” or something equivalent,
> > local
> >repositories used for pulling are used for nothing else -- this way in
> > the
> >event of a failed merge or a failed “fast forward” I can just drop the
> >concerning repository clone and reuse another local clone.
> >For development as a basic principle I prefer local repositories. Apart
> > from
> >rare emergency cases, I use remote repositories for publishing and
> > nothing
> >else.
> >
> > For the currently discussed use case of Christian this means:
> > • I would consider running the script remotely _only_ in the case of
> >full-fledged SSH access and after at least one remotely executed “hg
> > clone”.
> > • In any other case and assuming network access without WLAN shortcomings,
> >I would pull, clone locally at least once, run the script locally, check
> > the
> >result, if it satisfies then delete the remote repository and recreate
> > it by
> >pushing (deletion is required in this case because pushing allows only
> >appending).
> >
> > For _new_ projects I use git rather than mercurial since approximately two
> > years. Some of the reasons are:
> > • git is better documented: just compare
> >http://git-htmldocs.googlecode.com/git/git.html
> >http://mercurial.selenic.com/wiki/ManPages
>
> You need to compare `hg help {command}` and `git help {command}`. `git
> help {command}` redirects to `man git-{command}`, `hg help {command}`
> uses docstrings and command definitions. They both have a reason to
> provide documentation the way they do it:
>
> - Using `man` is simpler and it assumes that software (package manager
> mainly) used to install git addons is able to install man pages.
> - Using docstrings is more pythonic and `--editable` installs of
> mercurial extensions will for sure *not* provide man pages. This
> variant is more convenient for the extension developer.
>
> I can also say that while git is better documented, its documentation
> is *worse*. When I look at `hg help something` I usually understand
> immediately what I need to do. When I look at `git help something` I
> need to parse a lot of currently useless text, sometimes just to find
> out that I picked help for the wrong command.
I prefer the html-documentation, it allows more convenient jumping between
documents.
E.g. “git help log” and “git help diff” are huge man pages, yes, but this is
easily solved: I use the pager less, enter a perl search expression and
libpcre
does the parsing for me.
> > • In my experience git was the very first tool with complete and flawless
> >Unicode support -- even nowadays only few can compete in this concern
> >(perl-5.12+, zsh-5.0+). This stays in contrast to mercurial: “hg diff
> > …”
> >occasionally outputs invalid Unicode characters, because trimming of the
> >function name field ignores boundaries of multibyte characters -- this is
> >even noted in the mercurial repository since several years, and there
> > seems
> >to be no intention to fix the bug. I have discussed two other examples
> > of --
> >in my subjective view -- odd design decisions of mercurial with the
> >developers; the patches I offered have been rejected; this can be
> > found in
> >mercurial mailing list archives. More examples on request.
>
> It is interesting. I can understand why trimming does this (most of
> strings used by mercurial are `str` - byte strings), but do not
> understand why they do not have any fixes: this should be as trivial
> as “convert to `unicode` from encoding in current locale -> trim ->
> convert back”. If needed more efficient solutions are also trivial to
> implement, but they will contain more code.
+1
> > • For good reasons mercuri
Re: Repository cleanup (Was: Preparations for moving to github)
On 2015-04-15 Wednesday at 18:41 +0200 Bram Moolenaar wrote: > > Roland Eggner wrote: > > [...] > > > @Bram > > ─ > > As you prefer context over unified diff format: > > Only for the patches I send out. If someone sends me a patch any format > will do. > > > • Are you aware of the possibility, that both git and mercurial can be > >configured to output _every_ diff output with an increased number of > > The reason for context diffs is for very old systems, which are unlikely > to have git or mercurial. It's become less and less important, but it's > zero work to keep doing it this way. “very old systems” … now I understand your intention, thank you. > >context lines, e.g. 10 lines instead of the usual 3? > >“git log -p -1 -U10” > >gitconfig: “[diff] \n context = 10” > >“hg log -p --limit 1 --config diff.unified=10“ > >hgrc: “[diff] \n unified = 10“ > >“git help diff” describes even more options to tune the amount of diff > >context. > > • Are you aware of the patchutils package and the filterdiff command? > >It can give you context diff format with git and mercurial everywhere: > >just use “PAGER=/usr/bin/less” and properly include > >“filterdiff -v --format=context” in /usr/bin/lesspipe. > > If you do not use already something equivalent, maybe using any of > > this tips or both you like git and mercurial a bit more? -- Roland Eggner -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. pgpm2fqQzUcid.pgp Description: PGP signature
Re: Repository cleanup (Was: Preparations for moving to github)
Hi Markus! On Mi, 15 Apr 2015, Markus Heidelberg wrote: > Am Dienstag, 14. April 2015, 20:02:17 schrieb Christian Brabandt: > > Ubuntu 12.04 LTS: > > Mercurial Distributed SCM (version 2.0.2) > > (see http://mercurial.selenic.com for more information) > > Huh, pretty old from 2012-01-01 :) You know, server and so... > > > According to `hg annotate` tip~7 was committed at Sat Apr 30 17:43:04 > > > 2011 +0200. > > > > While hg log -r tip~7 worked, hg rebase complained that tip~7 was no > > valid revision number (or something like that, sorry, I did not keep the > > log). > > Support for these revision sets like tip~7 had been added to rebase on > 2011-10-15, but only for --source and --base [1]. > A few months later on 2012-05-01 it had been added to the --dest option [2]. > > [1] http://selenic.com/hg/rev/b12362ab13e7 > [2] http://selenic.com/hg/rev/ae6dddffe4f1 > > I've adapted the script to use a temporary local tag to store the rebase > destination and avoid the use of revision sets. Hope it works with your > version. > > diff -r b6c1f5d29ad3 -r 5109f92eb4e5 tools/clean_repo.sh Thanks. I'll keep that in mind, in case I have to do it again. Hopefully, I'll get a more updated hg in the meantime (I didn't know, that nowadays, one is so much dependent on a recent mercurial version. I mean, 12.04 LTS is not ancient and still a fully supported version...) Best, Christian -- Je weniger die Leute glauben, desto abergläubischer werden sie. -- Jeremias Gotthelf -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Roland Eggner wrote: [...] > @Bram > ─ > As you prefer context over unified diff format: Only for the patches I send out. If someone sends me a patch any format will do. > • Are you aware of the possibility, that both git and mercurial can be >configured to output _every_ diff output with an increased number of The reason for context diffs is for very old systems, which are unlikely to have git or mercurial. It's become less and less important, but it's zero work to keep doing it this way. >context lines, e.g. 10 lines instead of the usual 3? >“git log -p -1 -U10” >gitconfig: “[diff] \n context = 10” >“hg log -p --limit 1 --config diff.unified=10“ >hgrc: “[diff] \n unified = 10“ >“git help diff” describes even more options to tune the amount of diff >context. > • Are you aware of the patchutils package and the filterdiff command? >It can give you context diff format with git and mercurial everywhere: >just use “PAGER=/usr/bin/less” and properly include >“filterdiff -v --format=context” in /usr/bin/lesspipe. > If you do not use already something equivalent, maybe using any of > this tips or both you like git and mercurial a bit more? -- "I've been teaching myself to play the piano for about 5 years and now write most of my songs on it, mainly because I can never find any paper." Jeff Lynne, ELO's greatest hits /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Hello Christian and Nikolay Am Dienstag, 14. April 2015, 20:02:17 schrieb Christian Brabandt: > On Di, 14 Apr 2015, Nikolay Pavlov wrote: > > > 2015-04-14 20:45 GMT+03:00 Christian Brabandt : > > > Hi Markus! > > > > > > On Mo, 13 Apr 2015, Markus Heidelberg wrote: > > > > > > [...] > > >> hg rebase --dest tip~7 --source tip~6 --collapse -m"Add missing tags" > > > > > > I was brave and tested your script. There are two points I noticed. > > > 1) rebase needs to be enabled explicitly in your .hg/hgrc Or in ~/.hgrc Yes, I forgot to mention it, just for reference: [extensions] rebase = > > > 2) hg rebase does not seem to understand the tip~7 name > > > > It should. Wondering what is your mercurial version. > > Ubuntu 12.04 LTS: > Mercurial Distributed SCM (version 2.0.2) > (see http://mercurial.selenic.com for more information) Huh, pretty old from 2012-01-01 :) > > According to `hg annotate` tip~7 was committed at Sat Apr 30 17:43:04 2011 > > +0200. > > While hg log -r tip~7 worked, hg rebase complained that tip~7 was no > valid revision number (or something like that, sorry, I did not keep the > log). Support for these revision sets like tip~7 had been added to rebase on 2011-10-15, but only for --source and --base [1]. A few months later on 2012-05-01 it had been added to the --dest option [2]. [1] http://selenic.com/hg/rev/b12362ab13e7 [2] http://selenic.com/hg/rev/ae6dddffe4f1 I've adapted the script to use a temporary local tag to store the rebase destination and avoid the use of revision sets. Hope it works with your version. diff -r b6c1f5d29ad3 -r 5109f92eb4e5 tools/clean_repo.sh --- a/tools/clean_repo.sh Tue Apr 14 18:58:05 2015 +0200 +++ b/tools/clean_repo.sh Wed Apr 15 00:59:39 2015 +0200 @@ -80,6 +80,7 @@ # thing, see # http://mercurial.selenic.com/wiki/Tag # http://mercurial.selenic.com/wiki/TagDesign +hg tag -f --local rebasedest hg tag -f -r 2ec8266fa254f9f90fd302df275d2813ae08a8e6 v7-0-225 hg tag -f -r 042fa969dab175d414d611425d8a61424bacf75f v7-1-008 hg tag -f -r 12cecc379574aba2231cbba54c4eaeef3432db69 v7-2-080 @@ -112,13 +113,14 @@ The others have been moved to the correct changeset. EOF -hg rebase --dest tip~19 --source tip~18 --collapse --logfile logfile.txt +hg rebase --dest rebasedest --source tip~18 --collapse --logfile logfile.txt rm logfile.txt # remove unused tag hg tag -m"Remove unused tag from invalid line of history" --remove start # add missing tags +hg tag -f --local rebasedest hg tag -r f03c3fae0a99 v7-0-076 hg tag -r v7-2-000 v7-2 hg tag -r ee53a39d5896 v7-3 @@ -131,4 +133,7 @@ # Optionally squash all separate tag adding commits into one # with a proper description -hg rebase --dest tip~7 --source tip~6 --collapse -m"Add missing tags" +hg rebase --dest rebasedest --source tip~6 --collapse -m"Add missing tags" + +# cleanup +hg tag --local --remove rebasedest -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
2015-04-14 21:50 GMT+03:00 Nikolay Pavlov : > 2015-04-14 21:36 GMT+03:00 Christian Brabandt : >> >> On Di, 14 Apr 2015, Nikolay Pavlov wrote: >>> 2015-04-14 21:02 GMT+03:00 Christian Brabandt : >>> > On Di, 14 Apr 2015, Nikolay Pavlov wrote: >>> > >>> >> 2015-04-14 20:45 GMT+03:00 Christian Brabandt : >>> >> > Hi Markus! >>> >> > >>> >> > On Mo, 13 Apr 2015, Markus Heidelberg wrote: >>> >> > >>> >> > [...] >>> >> >> hg rebase --dest tip~7 --source tip~6 --collapse -m"Add missing tags" >>> >> > >>> >> > I was brave and tested your script. There are two points I noticed. >>> >> > 1) rebase needs to be enabled explicitly in your .hg/hgrc >>> >> > 2) hg rebase does not seem to understand the tip~7 name >>> >> >>> >> It should. Wondering what is your mercurial version. >>> > >>> > Ubuntu 12.04 LTS: >>> > Mercurial Distributed SCM (version 2.0.2) >>> > (see http://mercurial.selenic.com for more information) >>> > >>> > Copyright (C) 2005-2011 Matt Mackall and others >>> > This is free software; see the source for copying conditions. There is NO >>> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>> > PURPOSE. >>> > >>> >> According to `hg annotate` tip~7 was committed at Sat Apr 30 17:43:04 >>> >> 2011 +0200. >>> > >>> > While hg log -r tip~7 worked, hg rebase complained that tip~7 was no >>> > valid revision number (or something like that, sorry, I did not keep the >>> > log). >>> >>> Maybe you tried to rebase published revision? This is most common >>> rebase problem: if some commit is marked as published mercurial will >>> not allow you to rebase it. You need to use `hg phase` to set phase to >>> draft or secret then (note: draft revision can only have public or >>> draft parent, secret can only have public, draft or secret: don’t try >>> to change phase of *one* revision). >> >> No I worked locally and pushed only after I noticed rebase didn't work >> for me. > > You don’t need to push to get public revision. It is enough to pull > public revision. I do not see the script fixing phases. Though it should work on draft changesets, so it does not have to. I guess you need to update mercurial version. > >> >> Best, >> Christian >> -- >> Manche halten ihre veränderte Ansicht eines Menschen für eine >> Veränderung desselben. >> -- Jean Paul >> >> -- >> -- >> 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 vim_dev+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
2015-04-14 21:36 GMT+03:00 Christian Brabandt : > > On Di, 14 Apr 2015, Nikolay Pavlov wrote: >> 2015-04-14 21:02 GMT+03:00 Christian Brabandt : >> > On Di, 14 Apr 2015, Nikolay Pavlov wrote: >> > >> >> 2015-04-14 20:45 GMT+03:00 Christian Brabandt : >> >> > Hi Markus! >> >> > >> >> > On Mo, 13 Apr 2015, Markus Heidelberg wrote: >> >> > >> >> > [...] >> >> >> hg rebase --dest tip~7 --source tip~6 --collapse -m"Add missing tags" >> >> > >> >> > I was brave and tested your script. There are two points I noticed. >> >> > 1) rebase needs to be enabled explicitly in your .hg/hgrc >> >> > 2) hg rebase does not seem to understand the tip~7 name >> >> >> >> It should. Wondering what is your mercurial version. >> > >> > Ubuntu 12.04 LTS: >> > Mercurial Distributed SCM (version 2.0.2) >> > (see http://mercurial.selenic.com for more information) >> > >> > Copyright (C) 2005-2011 Matt Mackall and others >> > This is free software; see the source for copying conditions. There is NO >> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> > >> >> According to `hg annotate` tip~7 was committed at Sat Apr 30 17:43:04 >> >> 2011 +0200. >> > >> > While hg log -r tip~7 worked, hg rebase complained that tip~7 was no >> > valid revision number (or something like that, sorry, I did not keep the >> > log). >> >> Maybe you tried to rebase published revision? This is most common >> rebase problem: if some commit is marked as published mercurial will >> not allow you to rebase it. You need to use `hg phase` to set phase to >> draft or secret then (note: draft revision can only have public or >> draft parent, secret can only have public, draft or secret: don’t try >> to change phase of *one* revision). > > No I worked locally and pushed only after I noticed rebase didn't work > for me. You don’t need to push to get public revision. It is enough to pull public revision. I do not see the script fixing phases. > > Best, > Christian > -- > Manche halten ihre veränderte Ansicht eines Menschen für eine > Veränderung desselben. > -- Jean Paul > > -- > -- > 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 vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Di, 14 Apr 2015, Nikolay Pavlov wrote: > 2015-04-14 21:02 GMT+03:00 Christian Brabandt : > > On Di, 14 Apr 2015, Nikolay Pavlov wrote: > > > >> 2015-04-14 20:45 GMT+03:00 Christian Brabandt : > >> > Hi Markus! > >> > > >> > On Mo, 13 Apr 2015, Markus Heidelberg wrote: > >> > > >> > [...] > >> >> hg rebase --dest tip~7 --source tip~6 --collapse -m"Add missing tags" > >> > > >> > I was brave and tested your script. There are two points I noticed. > >> > 1) rebase needs to be enabled explicitly in your .hg/hgrc > >> > 2) hg rebase does not seem to understand the tip~7 name > >> > >> It should. Wondering what is your mercurial version. > > > > Ubuntu 12.04 LTS: > > Mercurial Distributed SCM (version 2.0.2) > > (see http://mercurial.selenic.com for more information) > > > > Copyright (C) 2005-2011 Matt Mackall and others > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > >> According to `hg annotate` tip~7 was committed at Sat Apr 30 17:43:04 2011 > >> +0200. > > > > While hg log -r tip~7 worked, hg rebase complained that tip~7 was no > > valid revision number (or something like that, sorry, I did not keep the > > log). > > Maybe you tried to rebase published revision? This is most common > rebase problem: if some commit is marked as published mercurial will > not allow you to rebase it. You need to use `hg phase` to set phase to > draft or secret then (note: draft revision can only have public or > draft parent, secret can only have public, draft or secret: don’t try > to change phase of *one* revision). No I worked locally and pushed only after I noticed rebase didn't work for me. Best, Christian -- Manche halten ihre veränderte Ansicht eines Menschen für eine Veränderung desselben. -- Jean Paul -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
2015-04-14 21:02 GMT+03:00 Christian Brabandt : > On Di, 14 Apr 2015, Nikolay Pavlov wrote: > >> 2015-04-14 20:45 GMT+03:00 Christian Brabandt : >> > Hi Markus! >> > >> > On Mo, 13 Apr 2015, Markus Heidelberg wrote: >> > >> > [...] >> >> hg rebase --dest tip~7 --source tip~6 --collapse -m"Add missing tags" >> > >> > I was brave and tested your script. There are two points I noticed. >> > 1) rebase needs to be enabled explicitly in your .hg/hgrc >> > 2) hg rebase does not seem to understand the tip~7 name >> >> It should. Wondering what is your mercurial version. > > Ubuntu 12.04 LTS: > Mercurial Distributed SCM (version 2.0.2) > (see http://mercurial.selenic.com for more information) > > Copyright (C) 2005-2011 Matt Mackall and others > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > >> According to `hg annotate` tip~7 was committed at Sat Apr 30 17:43:04 2011 >> +0200. > > While hg log -r tip~7 worked, hg rebase complained that tip~7 was no > valid revision number (or something like that, sorry, I did not keep the > log). Maybe you tried to rebase published revision? This is most common rebase problem: if some commit is marked as published mercurial will not allow you to rebase it. You need to use `hg phase` to set phase to draft or secret then (note: draft revision can only have public or draft parent, secret can only have public, draft or secret: don’t try to change phase of *one* revision). Of course after rebasing mercurial will not allow you to just push (and in any case push will not remove anything): editing public history is the worst idea ever in mercurial and when you go down this road you will find all kinds of obstacles. > > Best, > Christian > -- > Nimm dein Leben, wie es ist! Denke nicht: "So könnt' es sein." Fluche > keinem deiner Tage, was du tragen mußt, ertrage! > -- Bô Yin Râ (eigentlich: Joseph Anton Schneiderfranken) > > -- > -- > 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 vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Di, 14 Apr 2015, Christian Brabandt wrote: > On Di, 14 Apr 2015, Nikolay Pavlov wrote: > > > 2015-04-14 20:45 GMT+03:00 Christian Brabandt : > > > Hi Markus! > > > > > > On Mo, 13 Apr 2015, Markus Heidelberg wrote: > > > > > > [...] > > >> hg rebase --dest tip~7 --source tip~6 --collapse -m"Add missing tags" > > > > > > I was brave and tested your script. There are two points I noticed. > > > 1) rebase needs to be enabled explicitly in your .hg/hgrc > > > 2) hg rebase does not seem to understand the tip~7 name > > > > It should. Wondering what is your mercurial version. > > Ubuntu 12.04 LTS: > Mercurial Distributed SCM (version 2.0.2) > (see http://mercurial.selenic.com for more information) > > Copyright (C) 2005-2011 Matt Mackall and others > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > According to `hg annotate` tip~7 was committed at Sat Apr 30 17:43:04 2011 > > +0200. > > While hg log -r tip~7 worked, hg rebase complained that tip~7 was no > valid revision number (or something like that, sorry, I did not keep the > log). Oh and when I executed it manually using local revision numbers it told me "No rebase necessary" I think it must be making fun of me... Best, Christian -- Denn alles Vornehme ist eigentlich ablehnend. -- Johann Wolfgang von Goethe (Dichtung und Wahrheit III) -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
On Di, 14 Apr 2015, Nikolay Pavlov wrote: > 2015-04-14 20:45 GMT+03:00 Christian Brabandt : > > Hi Markus! > > > > On Mo, 13 Apr 2015, Markus Heidelberg wrote: > > > > [...] > >> hg rebase --dest tip~7 --source tip~6 --collapse -m"Add missing tags" > > > > I was brave and tested your script. There are two points I noticed. > > 1) rebase needs to be enabled explicitly in your .hg/hgrc > > 2) hg rebase does not seem to understand the tip~7 name > > It should. Wondering what is your mercurial version. Ubuntu 12.04 LTS: Mercurial Distributed SCM (version 2.0.2) (see http://mercurial.selenic.com for more information) Copyright (C) 2005-2011 Matt Mackall and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > According to `hg annotate` tip~7 was committed at Sat Apr 30 17:43:04 2011 > +0200. While hg log -r tip~7 worked, hg rebase complained that tip~7 was no valid revision number (or something like that, sorry, I did not keep the log). Best, Christian -- Nimm dein Leben, wie es ist! Denke nicht: "So könnt' es sein." Fluche keinem deiner Tage, was du tragen mußt, ertrage! -- Bô Yin Râ (eigentlich: Joseph Anton Schneiderfranken) -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
2015-04-14 20:45 GMT+03:00 Christian Brabandt : > Hi Markus! > > On Mo, 13 Apr 2015, Markus Heidelberg wrote: > > [...] >> hg rebase --dest tip~7 --source tip~6 --collapse -m"Add missing tags" > > I was brave and tested your script. There are two points I noticed. > 1) rebase needs to be enabled explicitly in your .hg/hgrc > 2) hg rebase does not seem to understand the tip~7 name It should. Wondering what is your mercurial version. According to `hg annotate` tip~7 was committed at Sat Apr 30 17:43:04 2011 +0200. According to the changelog it appeared in mercurial-1.9. > > So I skipped that part, as it seems more trouble than usefulness to make > this work. > > Best, > Christian > -- > Das ist das Teuflischste, was eine menschliche Hand tun kann. > Darum zahlen wir mit den schrecklichen Dingen, die in der Welt > geschehen. > -- Mutter Teresa > > -- > -- > 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 vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
Hi Markus! On Mo, 13 Apr 2015, Markus Heidelberg wrote: [...] > hg rebase --dest tip~7 --source tip~6 --collapse -m"Add missing tags" I was brave and tested your script. There are two points I noticed. 1) rebase needs to be enabled explicitly in your .hg/hgrc 2) hg rebase does not seem to understand the tip~7 name So I skipped that part, as it seems more trouble than usefulness to make this work. Best, Christian -- Das ist das Teuflischste, was eine menschliche Hand tun kann. Darum zahlen wir mit den schrecklichen Dingen, die in der Welt geschehen. -- Mutter Teresa -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
2015-04-14 17:37 GMT+03:00 Roland Eggner :
> On 2015-04-13 Monday at 20:00 +0200 Christian Brabandt wrote:
>> On Mo, 13 Apr 2015, Bram Moolenaar wrote:
>> > Markus Heidelberg wrote:
>> > > > 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).
>
>
> @Bram, @Markus
> ──
> Many thanks to Markus for the thorough work. After reading the proposed
> script
> I am convinced it will work as intended. It addresses the same odds of the
> vim
> repository, which I am seeing. I suggest just one addition:
>
> When cloned on a Linux system or another Unix-like system, the randomly set
> executability attributes of files in the vim repository are looking odd. The
> following shell script would turn the picture to a decent and useful look:
>
> find . -path ./.hg -prune -o -type f -exec chmod 640 '{}' + \\
> && find . -path ./.hg -prune -o -type f -regextype posix-extended \\
> -regex '.*(/configure|/mkinstalldirs|\.sh|\.pl)$' -exec chmod -c 750 '{}' + \\
> && hg commit -m 'Set reasonable executability attributes of files.'
>
>
> @Bram, @Christian, @all
> ───
> During some 10 years of almost daily usage of mercurial I have learned, I can
> usefully apply the philosophy, which Bram has provided in his book „Seven
> habits
> of effective text editing“:
> • Usage of a version management system will _save_ workload rather than to
>add workload, as soon as I switch from “insane” to “sane” thinking
> patterns.
> • Examples for “insane” thinking patterns are:
>How can I undo mercurial commands?
>How can I edit the repository?
>How can I work on a remote repository?
> • Examples for “sane” thinking and usage patterns are:
>Whenever I am not absolutely sure about the consequences of my next action,
>I run “hg clone …” firstly. On decent file systems this is cheap because
>only file names are copied, not file contents. Dependent on the outcome
>I drop the older or the newer repository later -- this way I have no need
> for
>any kind of undo actions and can relax.
>Every “hg pull” is followed by a “hg clone” or something equivalent, local
>repositories used for pulling are used for nothing else -- this way in the
>event of a failed merge or a failed “fast forward” I can just drop the
>concerning repository clone and reuse another local clone.
>For development as a basic principle I prefer local repositories. Apart
> from
>rare emergency cases, I use remote repositories for publishing and nothing
>else.
>
> For the currently discussed use case of Christian this means:
> • I would consider running the script remotely _only_ in the case of
>full-fledged SSH access and after at least one remotely executed “hg
> clone”.
> • In any other case and assuming network access without WLAN shortcomings,
>I would pull, clone locally at least once, run the script locally, check
> the
>result, if it satisfies then delete the remote repository and recreate it
> by
>pushing (deletion is required in this case because pushing allows only
>appending).
>
> For _new_ projects I use git rather than mercurial since approximately two
> years. Some of the reasons are:
> • git is better documented: just compare
>http://git-htmldocs.googlecode.com/git/git.html
>http://mercurial.selenic.com/wiki/ManPages
You need to compare `hg help {command}` and `git help {command}`. `git
help {command}` redirects to `man git-{command}`, `hg help {command}`
uses docstrings and command definitions. They both have a reason to
provide documentation the way they do it:
- Using `man` is sim
Re: Repository cleanup (Was: Preparations for moving to github)
On 2015-04-13 Monday at 20:00 +0200 Christian Brabandt wrote:
> On Mo, 13 Apr 2015, Bram Moolenaar wrote:
> > Markus Heidelberg wrote:
> > > > 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).
@Bram, @Markus
──
Many thanks to Markus for the thorough work. After reading the proposed
script
I am convinced it will work as intended. It addresses the same odds of the vim
repository, which I am seeing. I suggest just one addition:
When cloned on a Linux system or another Unix-like system, the randomly set
executability attributes of files in the vim repository are looking odd. The
following shell script would turn the picture to a decent and useful look:
find . -path ./.hg -prune -o -type f -exec chmod 640 '{}' + \\
&& find . -path ./.hg -prune -o -type f -regextype posix-extended \\
-regex '.*(/configure|/mkinstalldirs|\.sh|\.pl)$' -exec chmod -c 750 '{}' + \\
&& hg commit -m 'Set reasonable executability attributes of files.'
@Bram, @Christian, @all
───
During some 10 years of almost daily usage of mercurial I have learned, I can
usefully apply the philosophy, which Bram has provided in his book „Seven
habits
of effective text editing“:
• Usage of a version management system will _save_ workload rather than to
add workload, as soon as I switch from “insane” to “sane” thinking patterns.
• Examples for “insane” thinking patterns are:
How can I undo mercurial commands?
How can I edit the repository?
How can I work on a remote repository?
• Examples for “sane” thinking and usage patterns are:
Whenever I am not absolutely sure about the consequences of my next action,
I run “hg clone …” firstly. On decent file systems this is cheap because
only file names are copied, not file contents. Dependent on the outcome
I drop the older or the newer repository later -- this way I have no need
for
any kind of undo actions and can relax.
Every “hg pull” is followed by a “hg clone” or something equivalent, local
repositories used for pulling are used for nothing else -- this way in the
event of a failed merge or a failed “fast forward” I can just drop the
concerning repository clone and reuse another local clone.
For development as a basic principle I prefer local repositories. Apart
from
rare emergency cases, I use remote repositories for publishing and nothing
else.
For the currently discussed use case of Christian this means:
• I would consider running the script remotely _only_ in the case of
full-fledged SSH access and after at least one remotely executed “hg clone”.
• In any other case and assuming network access without WLAN shortcomings,
I would pull, clone locally at least once, run the script locally, check the
result, if it satisfies then delete the remote repository and recreate it by
pushing (deletion is required in this case because pushing allows only
appending).
For _new_ projects I use git rather than mercurial since approximately two
years. Some of the reasons are:
• git is better documented: just compare
http://git-htmldocs.googlecode.com/git/git.html
http://mercurial.selenic.com/wiki/ManPages
• In my experience git was the very first tool with complete and flawless
Unicode support -- even nowadays only few can compete in this concern
(perl-5.12+, zsh-5.0+). This stays in contrast to mercurial: “hg diff …”
occasionally outputs invalid Unicode characters, because trimming of the
function name field ignores boundaries of multibyte characters -- this is
even noted in the mercurial repository since several years
Re: Repository cleanup (Was: Preparations for moving to github)
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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
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. -- Wi n0t trei a h0liday in Sweden thi yer? "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
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: #!/bin/sh # Vim HG repository cleanup # close stale branches, switch back to default branch afterwards # This has the slightly bad visual side-effect of parallel development from the # previous branch head up to the corresponding closing commit in "hg log # --graph", but is the correct thing to do to avoid seemingly active branches # showing up in "hg branches" output. hg update -C vim hg commit --close-branch -m"Close invalid branch 'vim'" hg update -C vim72 hg commit --close-branch -m"Close unused branch 'vim72'" hg update -C vim73 hg commit --close-branch -m"Close old branch 'vim73'" hg update -C default # remove unused branch lines # However, since the network protocol works append-only, you cannot push it # to the public repo. This would have to be done directly on the server via SSH # or an admin interface. # And still this change would have no effect when pulling from existing # clones, it would have to be stripped there as well, so ignore this step. #hg strip vim #hg strip vim72 # find potentially wrong tags by checking whether the patch number had been # added to src/version.c in that changeset #for i in $(hg tags | grep -o "v7-.*-[^ ]*"); do hg diff -c $i src/version.c | grep -q "^+$(echo $i | sed -e 's/v7-.*-0*//')," || echo $i; done # result: # v7-4-415 # v7-4b-000 # v7-3-523 # v7-3-143 # v7-2-446 # v7-2-443 # v7-2-442 # v7-2-441 # v7-2-440 # v7-2-439 # v7-2-438 # v7-2-437 # v7-2-436 # v7-2-232 # v7-2-176 # v7-2-167fix # v7-2-168 # v7-2-082 # v7-2-080 # v7-2-000 # v7-2c-000 # v7-2b-000 # v7-2a-00 # v7-1-258 # v7-1-008 # v7-0-225 # determine the actually wrong tags after manual inspection # v7-4-415 # v7-2-446 # v7-2-443 # v7-2-442 # v7-2-441 # v7-2-440 # v7-2-439 # v7-2-438 # v7-2-437 # v7-2-436 # v7-2-232 # v7-2-176 # v7-2-167fix # v7-2-168 # v7-2-082 # v7-2-080 # v7-1-008 # v7-0-225 # fix the wrong tags # Do not edit the .hgta
Re: Repository cleanup (Was: Preparations for moving to github)
Hi Bram! On Mi, 01 Apr 2015, Bram Moolenaar wrote: > What will happen for the mirror in Mercurial then? If you mean the bitbucket mirror I have set up, I wouldn't be too concerned. First of all, it is currently in experimental state, until I figure out the complete workflow for git and how I can get the update better automatically. Currently the patches should be synced fairly automatic, but I don't know yet how to handle the tags yet. Secondly, depending on how much is fixed, I don't intend to fix the history there, until someone can give me some advise on how to do it in mercurial. (Theoretically, I could reimport the complete history from git, after it has been cleaned there, but I do want to save me that effort). Best, Christian -- Wer mit seinem Latein am Ende ist, sollte eine andere Sprache lernen! -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
