* Repo cpnversion progress report @ 2014-01-30 19:55 Eric S. Raymond 2014-01-30 20:11 ` Andreas Schwab 2014-01-30 21:23 ` Eli Zaretskii 0 siblings, 2 replies; 38+ messages in thread From: Eric S. Raymond @ 2014-01-30 19:55 UTC (permalink / raw) To: emacs-devel The current version of the reposurgeon conversion script follows. The header comment explains the major steps. Most can be sanity-checked by eyeball and a little investigation with git log or gitk; interested parties are invited to do so. If I'm missing any steps, tell me about it. # Lift specification for the Emacs conversion # # Does the following steps: # # 1. Delete junk lost+found branches # # 2. Map some remnant CVS user names to DVCS IDs # # 3. Delete most junk tags. A few will need to be removed by hand after the # fact in the live git repo because reposurgeon can't do it safely. (This # happens when the branch tip commit does not have a unique successor branch.) # # 4. Rename some branches that are in the remotes namespace despite # having been merged long since. # # 5. Delete the elpa branch. # # 6. Turn most fossil Bazaar and CVS references into action stamps. It's # OK if this list isn't quite complete yet, mapping most references will # make the remaining ones stand out so this script can be corrected. # # 7. Identify and convert .cvsignore and .bzrignore files. # # Not yet done: # # * Rename and deletion fixups for RCS attic files # # * Incorporate fixes-bug properties from Bazaar. # # * Squash commit cliques that were not properly merged during the # CVS lift. # # * Massage bug URLs in change comments into a canonical form. # ############################################################################ # # Remove junk lost+found branches. These contain only dummy commits, # apparently written as tests. # branch refs/tags/lost+found/12d398afa4d2b77d606b28fe43a2e5200c863419 delete branch refs/tags/lost+found/5cf718038f760d6dc2e21dee3ce98061a975488a delete branch refs/tags/lost+found/9a1501510c2a842e8597d695fec05563161a84b7 delete branch refs/tags/lost+found/d4cd8d7c34cc79dc4abd0fec33cec74afa33e2d0 delete branch refs/tags/lost+found/e387e14faeea08877c99ddf798d5a4c9f7999c72 delete branch refs/tags/lost+found/b2e45f822e55882dda1bb80ca8b845d062d6d523 delete branch refs/tags/lost+found/c003b5d7e29f2b7c3c340d4aa851a61cfa481ec8 delete # # Fix up some CVS usernames that apparently didn't get converted during # the CVS lift. # authors read <<EOF thomas = Thomas Bushnell <thomas@gnu.ai.mit.edu> monnier = Stefan Monnier <monnier@iro.umontreal.ca> EOF # # Tag cleanup. # # All the Emacs tags are lightweight, hence the macro. # Tag deletions commented out with ## need to be done in git because # their tip commits don't have unique successor branches. This # exposes an underspecification hole reposurgeon won't go near. # define tagdelete tag tags/{0} delete define tagrename tag tags/{0} rename tags/{1} do tagdelete 0.1 ##do tagdelete Boehm-GC-base ##do tagdelete CEDET_BASE do tagrename EMACS_19_34 emacs-19.34 do tagrename EMACS_20_1 emacs-20.1 do tagrename EMACS_20_2 emacs-20.2 do tagrename EMACS_20_3 emacs-20.3 do tagrename EMACS_20_4 emacs-20.4 do tagrename EMACS_21_1 emacs-21.1 ##do tagdelete EMACS_21_1_BASE do tagrename EMACS_21_2 emacs-21.2 do tagrename EMACS_21_3 emacs-21.3 do tagrename EMACS_22_1 emacs-22.1 do tagrename EMACS_22_2 emacs-22.2 do tagrename EMACS_22_3 emacs-22.3 ##do tagdelete EMACS_22_BRANCHPOINT do tagrename EMACS_23_1 emacs-23.1 ##do tagdelete EMACS_23_1_BASE do tagrename EMACS_23_2 emacs-23.2 do tagrename EMACS_23_3 emacs-23.3 do tagrename EMACS_23_4 emacs-23.4 do tagrename EMACS_PRETEST_21_0_100 emacs-pretest-21.0.100 do tagrename EMACS_PRETEST_21_0_101 emacs-pretest-21.0.101 do tagrename EMACS_PRETEST_21_0_102 emacs-pretest-21.0.102 do tagrename EMACS_PRETEST_21_0_103 emacs-pretest-21.0.103 do tagrename EMACS_PRETEST_21_0_104 emacs-pretest-21.0.104 do tagrename EMACS_PRETEST_21_0_105 emacs-pretest-21.0.105 do tagrename EMACS_PRETEST_21_0_106 emacs-pretest-21.0.106 do tagrename EMACS_PRETEST_21_0_90 emacs-pretest-21.0.90 do tagrename EMACS_PRETEST_21_0_91 emacs-pretest-21.0.91 do tagrename EMACS_PRETEST_21_0_92 emacs-pretest-21.0.92 do tagrename EMACS_PRETEST_21_0_93 emacs-pretest-21.0.93 do tagrename EMACS_PRETEST_21_0_95 emacs-pretest-21.0.95 do tagrename EMACS_PRETEST_21_0_96 emacs-pretest-21.0.96 do tagrename EMACS_PRETEST_21_0_97 emacs-pretest-21.0.97 do tagrename EMACS_PRETEST_21_0_98 emacs-pretest-21.0.98 do tagrename EMACS_PRETEST_21_0_99 emacs-pretest-21.0.99 do tagrename EMACS_PRETEST_21_2_91 emacs-pretest-21.2.91 do tagrename EMACS_PRETEST_21_2_92 emacs-pretest-21.2.92 do tagrename EMACS_PRETEST_21_2_93 emacs-pretest-21.2.93 do tagrename EMACS_PRETEST_21_2_94 emacs-pretest-21.2.94 do tagrename EMACS_PRETEST_21_2_95 emacs-pretest-21.2.95 do tagrename EMACS_PRETEST_22_0_90 emacs-pretest-22.0.90 do tagrename EMACS_PRETEST_22_0_91 emacs-pretest-22.0.91 do tagrename EMACS_PRETEST_22_0_92 emacs-pretest-22.0.92 do tagrename EMACS_PRETEST_22_0_93 emacs-pretest-22.0.93 do tagrename EMACS_PRETEST_22_0_94 emacs-pretest-22.0.94 do tagrename EMACS_PRETEST_22_0_95 emacs-pretest-22.0.95 do tagrename EMACS_PRETEST_22_0_96 emacs-pretest-22.0.96 do tagrename EMACS_PRETEST_22_0_97 emacs-pretest-22.0.97 do tagrename EMACS_PRETEST_22_0_98 emacs-pretest-22.0.98 do tagrename EMACS_PRETEST_22_0_99 emacs-pretest-22.0.99 do tagrename EMACS_PRETEST_22_0_990 emacs-pretest-22.0.990 do tagrename EMACS_PRETEST_22_1_90 emacs-pretest-22.1.90 do tagrename EMACS_PRETEST_22_1_91 emacs-pretest-22.1.91 do tagrename EMACS_PRETEST_22_1_92 emacs-pretest-22.1.92 do tagrename EMACS_PRETEST_22_2_90 emacs-pretest-22.2.90 do tagrename EMACS_PRETEST_22_2_91 emacs-pretest-22.2.91 do tagrename EMACS_PRETEST_22_2_92 emacs-pretest-22.2.92 do tagrename EMACS_PRETEST_23_0_90 emacs-pretest-23.0.90 do tagrename EMACS_PRETEST_23_0_91 emacs-pretest-23.0.91 do tagrename EMACS_PRETEST_23_0_92 emacs-pretest-23.0.92 do tagrename EMACS_PRETEST_23_0_93 emacs-pretest-23.0.93 do tagrename EMACS_PRETEST_23_0_94 emacs-pretest-23.0.94 do tagrename EMACS_PRETEST_23_0_95 emacs-pretest-23.0.95 do tagrename EMACS_PRETEST_23_0_96 emacs-pretest-23.0.96 do tagrename EMACS_PRETEST_23_1_90 emacs-pretest-23.1.90 do tagrename EMACS_PRETEST_23_1_91 emacs-pretest-23.1.91 do tagrename EMACS_PRETEST_23_1_92 emacs-pretest-23.1.92 do tagrename EMACS_PRETEST_23_1_93 emacs-pretest-23.1.93 do tagrename EMACS_PRETEST_23_1_94 emacs-pretest-23.1.94 do tagrename EMACS_PRETEST_23_1_95 emacs-pretest-23.1.95 do tagrename EMACS_PRETEST_23_1_96 emacs-pretest-23.1.96 do tagrename EMACS_PRETEST_23_1_97 emacs-pretest-23.1.97 do tagrename EMACS_PRETEST_23_2_90 emacs-pretest-23.2.90 do tagrename EMACS_PRETEST_23_2_91 emacs-pretest-23.2.91 do tagrename EMACS_PRETEST_23_2_92 emacs-pretest-23.2.92 do tagrename EMACS_PRETEST_23_2_93 emacs-pretest-23.2.93 do tagrename EMACS_PRETEST_23_2_93_1 emacs-pretest-23.2.93.1 do tagrename EMACS_PRETEST_23_2_94 emacs-pretest-23.2.94 do tagrename EMACS_PRETEST_23_3_90 emacs-pretest-23.3.90 do tagrename EMACS_PRETEST_24_0_05 emacs-pretest-24.0.05 do tagrename EMACS_PRETEST_24_0_90 emacs-pretest-24.0.90 do tagrename EMACS_PRETEST_24_0_91 emacs-pretest-24.0.91 do tagrename EMACS_PRETEST_24_0_92 emacs-pretest-24.0.92 do tagrename EMACS_PRETEST_24_0_93 emacs-pretest-24.0.93 do tagrename EMACS_PRETEST_24_0_94 emacs-pretest-24.0.94 do tagrename EMACS_PRETEST_24_0_95 emacs-pretest-24.0.95 do tagdelete Ilya_4_23 do tagdelete Ilya_4_32 do tagdelete Ilya_4_35 do tagdelete Ilya_5_0 do tagdelete Ilya_5_10 do tagdelete Ilya_5_22 do tagdelete Ilya_5_23 do tagdelete Ilya_5_3 do tagdelete Ilya_5_7 ##do tagdelete NewVC-fileset-BASE ##do tagdelete RMAIL-MBOX-BASE do tagdelete Release_5_25 do tagdelete URL_2004-04-04_01h16 do tagdelete VENDOR-3_3 do tagdelete VENDOR-3_4 do tagdelete VENDOR-3_5 do tagdelete VENDOR-3_6 ##do tagdelete XFT_JHD_BRANCH_base do tagdelete after-merge-gnus-5_10 do tagdelete amigados-merge do tagdelete before-merge-emacs-app-to-trunk do tagdelete before-merge-gnus-5_10 do tagdelete before-merge-multi-tty-to-trunk do tagdelete before-merge-unicode-to-trunk do tagdelete before-miles-orphaned-changes do tagdelete before-remove-carbon do tagdelete before-remove-vms do tagdelete before-thomas-posix1996 ##do tagdelete branchpoint-5_8 ##do tagdelete custom_themes_branchpoint # keep emacs-19.34 # keep emacs-20.1 # keep emacs-20.2 # keep emacs-20.3 # keep emacs-20.4 # keep emacs-21.1 # keep emacs-21.2 # keep emacs-21.3 # keep emacs-22.1 # keep emacs-22.2 # keep emacs-22.3 # keep emacs-23.1 # keep emacs-23.2 # keep emacs-23.3 # keep emacs-23.4 do tagdelete emacs-23/emacs-23.2 # keep emacs-24.0.96 # keep emacs-24.0.97 # keep emacs-24.1 # keep emacs-24.2 # keep emacs-24.2.90 # keep emacs-24.2.91 # keep emacs-24.2.92 # keep emacs-24.2.93 # keep emacs-24.3 ##do tagdelete emacs-24.3-base # keep emacs-24.3-rc1 ##do tagdelete emacs-bidi-base ##do tagdelete emacs-unicode-2-base do tagdelete emacs-unicode-2-pre-sync ##do tagdelete emacs-unicode-base ##do tagdelete font-backend-base do tagdelete gcc-2_8_1-980401 do tagdelete gcc-2_8_1-980402 do tagdelete gcc-2_8_1-980407 do tagdelete gcc-2_8_1-980412 do tagdelete gcc-2_8_1-980413 do tagdelete gcc-2_8_1-980419 do tagdelete gcc-2_8_1-980426 do tagdelete gcc-2_8_1-980502 do tagdelete gcc-2_8_1-980513 do tagdelete gcc-2_8_1-980525 do tagdelete gcc-2_8_1-980529 do tagdelete gcc-2_8_1-980608 do tagdelete gcc-2_8_1-980609 do tagdelete gcc-2_8_1-980627 do tagdelete gcc-2_8_1-980705 do tagdelete gcc-2_8_1-980718 do tagdelete gcc-2_8_1-980811 do tagdelete gcc-2_8_1-980813 do tagdelete gcc-2_8_1-980928 do tagdelete gcc-2_8_1-980929 do tagdelete gcc-2_8_1-RELEASE do tagdelete gcc_2_8_1-980315 do tagdelete gcc_2_8_1-980929 do tagdelete glibc-2_0_2 do tagdelete glibc-2_0_4 do tagdelete gnumach-release-1-1 do tagdelete gnumach-release-1-1-1 do tagdelete gnumach-release-1-1-2 do tagdelete gnumach-release-1-1-3 do tagdelete gnus-5_10-branchpoint do tagdelete gnus-5_10-post-merge-josefsson do tagdelete gnus-5_10-post-merge-yamaoka do tagdelete gnus-5_10-pre-merge-josefsson do tagdelete gnus-5_10-pre-merge-yamaoka do tagdelete handa-temp-tag do tagdelete hurd-release-0-2 do tagdelete jimb-sync-Nov-3-1992 do tagdelete kfs_20030524_post do tagdelete kfs_20030524_pre ##do tagdelete lexbind-base do tagdelete libc-1-90 do tagdelete libc-1-91 do tagdelete libc-1-92 do tagdelete libc-1-93 do tagdelete libc-950402 do tagdelete libc-950411 do tagdelete libc-950722 do tagdelete libc-950723 do tagdelete libc-950922 do tagdelete libc-951016 do tagdelete libc-951018 do tagdelete libc-951029 do tagdelete libc-951031 do tagdelete libc-951101 do tagdelete libc-951102 do tagdelete libc-951103 do tagdelete libc-951104 do tagdelete libc-951105 do tagdelete libc-951106 do tagdelete libc-951107 do tagdelete libc-951108 do tagdelete libc-951109 do tagdelete libc-951110 do tagdelete libc-951111 do tagdelete libc-951112 do tagdelete libc-951113 do tagdelete libc-951114 do tagdelete libc-951115 do tagdelete libc-951116 do tagdelete libc-951117 do tagdelete libc-951118 do tagdelete libc-951119 do tagdelete libc-951120 do tagdelete libc-951121 do tagdelete libc-951122 do tagdelete libc-951123 do tagdelete libc-951124 do tagdelete libc-951125 do tagdelete libc-951126 do tagdelete libc-951127 do tagdelete libc-951128 do tagdelete libc-951129 do tagdelete libc-951130 do tagdelete libc-951201 do tagdelete libc-951202 do tagdelete libc-951203 do tagdelete libc-951204 do tagdelete libc-951206 do tagdelete libc-951208 do tagdelete libc-951209 do tagdelete libc-951210 do tagdelete libc-951211 do tagdelete libc-951212 do tagdelete libc-951213 do tagdelete libc-951214 do tagdelete libc-951215 do tagdelete libc-951216 do tagdelete libc-951217 do tagdelete libc-951218 do tagdelete libc-951219 do tagdelete libc-951220 do tagdelete libc-951221 do tagdelete libc-951222 do tagdelete libc-951223 do tagdelete libc-951224 do tagdelete libc-951225 do tagdelete libc-951226 do tagdelete libc-951227 do tagdelete libc-951228 do tagdelete libc-951229 do tagdelete libc-951230 do tagdelete libc-951231 do tagdelete libc-960101 do tagdelete libc-960102 do tagdelete libc-960103 do tagdelete libc-960104 do tagdelete libc-960105 do tagdelete libc-960106 do tagdelete libc-960107 do tagdelete libc-960108 do tagdelete libc-960109 do tagdelete libc-960110 do tagdelete libc-960111 do tagdelete libc-960112 do tagdelete libc-960113 do tagdelete libc-960114 do tagdelete libc-960115 do tagdelete libc-960116 do tagdelete libc-960117 do tagdelete libc-960118 do tagdelete libc-960119 do tagdelete libc-960120 do tagdelete libc-960121 do tagdelete libc-960122 do tagdelete libc-960123 do tagdelete libc-960124 do tagdelete libc-960125 do tagdelete libc-960126 do tagdelete libc-960127 do tagdelete libc-960128 do tagdelete libc-960129 do tagdelete libc-960130 do tagdelete libc-960131 do tagdelete libc-960201 do tagdelete libc-960202 do tagdelete libc-960203 do tagdelete libc-960204 do tagdelete libc-960205 do tagdelete libc-960206 do tagdelete libc-960207 do tagdelete libc-960208 do tagdelete libc-960209 do tagdelete libc-960210 do tagdelete libc-960211 do tagdelete libc-960212 do tagdelete libc-960213 do tagdelete libc-960214 do tagdelete libc-960215 do tagdelete libc-960216 do tagdelete libc-960217 do tagdelete libc-960218 do tagdelete libc-960219 do tagdelete libc-960220 do tagdelete libc-960221 do tagdelete libc-960222 do tagdelete libc-960223 do tagdelete libc-960224 do tagdelete libc-960225 do tagdelete libc-960226 do tagdelete libc-960227 do tagdelete libc-960228 do tagdelete libc-960229 do tagdelete libc-960302 do tagdelete libc-960303 do tagdelete libc-960304 do tagdelete libc-960305 do tagdelete libc-960306 do tagdelete libc-960307 do tagdelete libc-960308 do tagdelete libc-960309 do tagdelete libc-960310 do tagdelete libc-960311 do tagdelete libc-960312 do tagdelete libc-960313 do tagdelete libc-960314 do tagdelete libc-960315 do tagdelete libc-960316 do tagdelete libc-960317 do tagdelete libc-960318 do tagdelete libc-960319 do tagdelete libc-960320 do tagdelete libc-960321 do tagdelete libc-960322 do tagdelete libc-960323 do tagdelete libc-960324 do tagdelete libc-960325 do tagdelete libc-960326 do tagdelete libc-960327 do tagdelete libc-960328 do tagdelete libc-960329 do tagdelete libc-960330 do tagdelete libc-960331 do tagdelete libc-960401 do tagdelete libc-960402 do tagdelete libc-960403 do tagdelete libc-960404 do tagdelete libc-960405 do tagdelete libc-960406 do tagdelete libc-960407 do tagdelete libc-960408 do tagdelete libc-960409 do tagdelete libc-960410 do tagdelete libc-960411 do tagdelete libc-960412 do tagdelete libc-960413 do tagdelete libc-960414 do tagdelete libc-960415 do tagdelete libc-960416 do tagdelete libc-960417 do tagdelete libc-960418 do tagdelete libc-960419 do tagdelete libc-960420 do tagdelete libc-960421 do tagdelete libc-960422 do tagdelete libc-960423 do tagdelete libc-960424 do tagdelete libc-960425 do tagdelete libc-960426 do tagdelete libc-960427 do tagdelete libc-960428 do tagdelete libc-960429 do tagdelete libc-960430 do tagdelete libc-960501 do tagdelete libc-960502 do tagdelete libc-960503 do tagdelete libc-960504 do tagdelete libc-960505 do tagdelete libc-960506 do tagdelete libc-960507 do tagdelete libc-960508 do tagdelete libc-960509 do tagdelete libc-960510 do tagdelete libc-960511 do tagdelete libc-960512 do tagdelete libc-960513 do tagdelete libc-960514 do tagdelete libc-960515 do tagdelete libc-960516 do tagdelete libc-960517 do tagdelete libc-960518 do tagdelete libc-960519 do tagdelete libc-960520 do tagdelete libc-960521 do tagdelete libc-960522 do tagdelete libc-960523 do tagdelete libc-960524 do tagdelete libc-960525 do tagdelete libc-960526 do tagdelete libc-960527 do tagdelete libc-960528 do tagdelete libc-960529 do tagdelete libc-960530 do tagdelete libc-960531 do tagdelete libc-960601 do tagdelete libc-960602 do tagdelete libc-960603 do tagdelete libc-960604 do tagdelete libc-960605 do tagdelete libc-960606 do tagdelete libc-960607 do tagdelete libc-960608 do tagdelete libc-960609 do tagdelete libc-960610 do tagdelete libc-960611 do tagdelete libc-960612 do tagdelete libc-960613 do tagdelete libc-960614 do tagdelete libc-960615 do tagdelete libc-960616 do tagdelete libc-960617 do tagdelete libc-960618 do tagdelete libc-960619 do tagdelete libc-960620 do tagdelete libc-960621 do tagdelete libc-960622 do tagdelete libc-960623 do tagdelete libc-960624 do tagdelete libc-960625 do tagdelete libc-960626 do tagdelete libc-960627 do tagdelete libc-960628 do tagdelete libc-960629 do tagdelete libc-960630 do tagdelete libc-960701 do tagdelete libc-960702 do tagdelete libc-960703 do tagdelete libc-960704 do tagdelete libc-960705 do tagdelete libc-960706 do tagdelete libc-960707 do tagdelete libc-960708 do tagdelete libc-960709 do tagdelete libc-960710 do tagdelete libc-960711 do tagdelete libc-960712 do tagdelete libc-960713 do tagdelete libc-960714 do tagdelete libc-960715 do tagdelete libc-960716 do tagdelete libc-960717 do tagdelete libc-960718 do tagdelete libc-960719 do tagdelete libc-960720 do tagdelete libc-960721 do tagdelete libc-960722 do tagdelete libc-960723 do tagdelete libc-960724 do tagdelete libc-960725 do tagdelete libc-960726 do tagdelete libc-960727 do tagdelete libc-960728 do tagdelete libc-960729 do tagdelete libc-960730 do tagdelete libc-960731 do tagdelete libc-960801 do tagdelete libc-960802 do tagdelete libc-960803 do tagdelete libc-960804 do tagdelete libc-960805 do tagdelete libc-960806 do tagdelete libc-960807 do tagdelete libc-960808 do tagdelete libc-960809 do tagdelete libc-960810 do tagdelete libc-960811 do tagdelete libc-960812 do tagdelete libc-960813 do tagdelete libc-960814 do tagdelete libc-960815 do tagdelete libc-960816 do tagdelete libc-960817 do tagdelete libc-960818 do tagdelete libc-960819 do tagdelete libc-960820 do tagdelete libc-960821 do tagdelete libc-960822 do tagdelete libc-960823 do tagdelete libc-960824 do tagdelete libc-960825 do tagdelete libc-960826 do tagdelete libc-960827 do tagdelete libc-960828 do tagdelete libc-960829 do tagdelete libc-960830 do tagdelete libc-960831 do tagdelete libc-960901 do tagdelete libc-960902 do tagdelete libc-960903 do tagdelete libc-960904 do tagdelete libc-960905 do tagdelete libc-960906 do tagdelete libc-960907 do tagdelete libc-960908 do tagdelete libc-960909 do tagdelete libc-960910 do tagdelete libc-960911 do tagdelete libc-960912 do tagdelete libc-960913 do tagdelete libc-960918 do tagdelete libc-960919 do tagdelete libc-960920 do tagdelete libc-960921 do tagdelete libc-960922 do tagdelete libc-960923 do tagdelete libc-960925 do tagdelete libc-960926 do tagdelete libc-960927 do tagdelete libc-960928 do tagdelete libc-960929 do tagdelete libc-961001 do tagdelete libc-961004 do tagdelete libc-961005 do tagdelete libc-961006 do tagdelete libc-961007 do tagdelete libc-961008 do tagdelete libc-961009 do tagdelete libc-961010 do tagdelete libc-961011 do tagdelete libc-961012 do tagdelete libc-961013 do tagdelete libc-961014 do tagdelete libc-961015 do tagdelete libc-961016 do tagdelete libc-961017 do tagdelete libc-961018 do tagdelete libc-961019 do tagdelete libc-961020 do tagdelete libc-961021 do tagdelete libc-961022 do tagdelete libc-961023 do tagdelete libc-961024 do tagdelete libc-961025 do tagdelete libc-961026 do tagdelete libc-961027 do tagdelete libc-961028 do tagdelete libc-961029 do tagdelete libc-961030 do tagdelete libc-961031 do tagdelete libc-961101 do tagdelete libc-961102 do tagdelete libc-961103 do tagdelete libc-961104 do tagdelete libc-961105 do tagdelete libc-961106 do tagdelete libc-961107 do tagdelete libc-961108 do tagdelete libc-961109 do tagdelete libc-961110 do tagdelete libc-961111 do tagdelete libc-961114 do tagdelete libc-961115 do tagdelete libc-961116 do tagdelete libc-961117 do tagdelete libc-961118 do tagdelete libc-961119 do tagdelete libc-961120 do tagdelete libc-961121 do tagdelete libc-961203 do tagdelete libc-961204 do tagdelete libc-961205 do tagdelete libc-961206 do tagdelete libc-961207 do tagdelete libc-961208 do tagdelete libc-961209 do tagdelete libc-961210 do tagdelete libc-961211 do tagdelete libc-961212 do tagdelete libc-961213 do tagdelete libc-961214 do tagdelete libc-961215 do tagdelete libc-961216 do tagdelete libc-961217 do tagdelete libc-961218 do tagdelete libc-961219 do tagdelete libc-961220 do tagdelete libc-961221 do tagdelete libc-961222 do tagdelete libc-961223 do tagdelete libc-961224 do tagdelete libc-961225 do tagdelete libc-961226 do tagdelete libc-961227 do tagdelete libc-961228 do tagdelete libc-961229 do tagdelete libc-961230 do tagdelete libc-961231 do tagdelete libc-970101 do tagdelete libc-970102 do tagdelete libc-970103 do tagdelete libc-970104 do tagdelete libc-970105 do tagdelete libc-970106 do tagdelete libc-970107 do tagdelete libc-970108 do tagdelete libc-970109 do tagdelete libc-970110 do tagdelete libc-970111 do tagdelete libc-970112 do tagdelete libc-970113 do tagdelete libc-970114 do tagdelete libc-970115 do tagdelete libc-970116 do tagdelete libc-970117 do tagdelete libc-970118 do tagdelete libc-970119 do tagdelete libc-970120 do tagdelete libc-970121 do tagdelete libc-970122 do tagdelete libc-970123 do tagdelete libc-970124 do tagdelete libc-970125 do tagdelete libc-970126 do tagdelete libc-970127 do tagdelete libc-970128 do tagdelete libc-970129 do tagdelete libc-970130 do tagdelete libc-970131 do tagdelete libc-970201 do tagdelete libc-970202 do tagdelete libc-970203 do tagdelete libc-970204 do tagdelete libc-970205 do tagdelete libc-970206 do tagdelete libc-970207 do tagdelete libc-970208 do tagdelete libc-970209 do tagdelete libc-970210 do tagdelete libc-970211 do tagdelete libc-970212 do tagdelete libc-970213 do tagdelete libc-970214 do tagdelete libc-970215 do tagdelete libc-970216 do tagdelete libc-970217 do tagdelete libc-970218 do tagdelete libc-970219 do tagdelete libc-970220 do tagdelete libc-970221 do tagdelete libc-970222 do tagdelete libc-970223 do tagdelete libc-970224 do tagdelete libc-970225 do tagdelete libc-970226 do tagdelete libc-970227 do tagdelete libc-970228 do tagdelete libc-970301 do tagdelete libc-970302 do tagdelete libc-970303 do tagdelete libc-970304 do tagdelete libc-970305 do tagdelete libc-970306 do tagdelete libc-970307 do tagdelete libc-970308 do tagdelete libc-970309 do tagdelete libc-970310 do tagdelete libc-970311 do tagdelete libc-970312 do tagdelete libc-970313 do tagdelete libc-970314 do tagdelete libc-970315 do tagdelete libc-970316 do tagdelete libc-970317 do tagdelete libc-970318 do tagdelete libc-970319 do tagdelete libc-970320 do tagdelete libc-970321 do tagdelete libc-970322 do tagdelete libc-970323 do tagdelete libc-970324 do tagdelete libc-970325 do tagdelete libc-970326 do tagdelete libc-970327 do tagdelete libc-970328 do tagdelete libc-970329 do tagdelete libc-970330 do tagdelete libc-970331 do tagdelete libc-970401 do tagdelete libc-970402 do tagdelete libc-970403 do tagdelete libc-970404 do tagdelete libc-970405 do tagdelete libc-970406 do tagdelete libc-970407 do tagdelete libc-970408 do tagdelete libc-970409 do tagdelete libc-970410 do tagdelete libc-970411 do tagdelete libc-970412 do tagdelete libc-970413 do tagdelete libc-970414 do tagdelete libc-970415 do tagdelete libc-970416 do tagdelete libc-970417 do tagdelete libc-970418 do tagdelete libc-970419 do tagdelete libc-970420 do tagdelete libc-970421 do tagdelete libc-970422 do tagdelete libc-970423 do tagdelete libc-970424 do tagdelete libc-970425 do tagdelete libc-970426 do tagdelete libc-970427 do tagdelete libc-970428 do tagdelete libc-970429 do tagdelete libc-970430 do tagdelete libc-970501 do tagdelete libc-970502 do tagdelete libc-970503 do tagdelete libc-970504 do tagdelete libc-970505 do tagdelete libc-970506 do tagdelete libc-970507 do tagdelete libc-970508 do tagdelete libc-970509 do tagdelete libc-970510 do tagdelete libc-970511 do tagdelete libc-970512 do tagdelete libc-970513 do tagdelete libc-970514 do tagdelete libc-970515 do tagdelete libc-970516 do tagdelete libc-970517 do tagdelete libc-970518 do tagdelete libc-970519 do tagdelete libc-970520 do tagdelete libc-970521 do tagdelete libc-970522 do tagdelete libc-970523 do tagdelete libc-970524 do tagdelete libc-970525 do tagdelete libc-970526 do tagdelete libc-970527 do tagdelete libc-970528 do tagdelete libc-970529 do tagdelete libc-970530 do tagdelete libc-970531 do tagdelete libc-970601 do tagdelete libc-970602 do tagdelete libc-970603 do tagdelete libc-970604 do tagdelete libc-970605 do tagdelete libc-970606 do tagdelete libc-970607 do tagdelete libc-970608 do tagdelete libc-970609 do tagdelete libc-970610 do tagdelete libc-970611 do tagdelete libc-970612 do tagdelete libc-970613 do tagdelete libc-970614 do tagdelete libc-970615 do tagdelete libc-970616 do tagdelete libc-970617 do tagdelete libc-970618 do tagdelete libc-970619 do tagdelete libc-970620 do tagdelete libc-970621 do tagdelete libc-970622 do tagdelete libc-970624 do tagdelete libc-970625 do tagdelete libc-970626 do tagdelete libc-970627 do tagdelete libc-970628 do tagdelete libc-970629 do tagdelete libc-970630 do tagdelete libc-970701 do tagdelete libc-970702 do tagdelete libc-970703 do tagdelete libc-970704 do tagdelete libc-970705 do tagdelete libc-970707 do tagdelete libc-970708 do tagdelete libc-970709 do tagdelete libc-970710 do tagdelete libc-970713 do tagdelete libc-970715 do tagdelete libc-970717 do tagdelete libc-970718 do tagdelete libc-970719 do tagdelete libc-970720 do tagdelete libc-970721 do tagdelete libc-970722 do tagdelete libc-970723 do tagdelete libc-970724 do tagdelete libc-970725 do tagdelete libc-970726 do tagdelete libc-970727 do tagdelete libc-970728 do tagdelete libc-970729 do tagdelete libc-970730 do tagdelete libc-970731 do tagdelete libc-970801 do tagdelete libc-970802 do tagdelete libc-970803 do tagdelete libc-970804 do tagdelete libc-970805 do tagdelete libc-970806 do tagdelete libc-970807 do tagdelete libc-970808 do tagdelete libc-970809 do tagdelete libc-970810 do tagdelete libc-970811 do tagdelete libc-970812 do tagdelete libc-970813 do tagdelete libc-970814 do tagdelete libc-970815 do tagdelete libc-970816 do tagdelete libc-970817 do tagdelete libc-970818 do tagdelete libc-970819 do tagdelete libc-970820 do tagdelete libc-970821 do tagdelete libc-970822 do tagdelete libc-970823 do tagdelete libc-970824 do tagdelete libc-970825 do tagdelete libc-970826 do tagdelete libc-970827 do tagdelete libc-970828 do tagdelete libc-970829 do tagdelete libc-970830 do tagdelete libc-970831 do tagdelete libc-970901 do tagdelete libc-970902 do tagdelete libc-970903 do tagdelete libc-970904 do tagdelete libc-970905 do tagdelete libc-970906 do tagdelete libc-970907 do tagdelete libc-970908 do tagdelete libc-970911 do tagdelete libc-970912 do tagdelete libc-970913 do tagdelete libc-970914 do tagdelete libc-970915 do tagdelete libc-970916 do tagdelete libc-970917 do tagdelete libc-970918 do tagdelete libc-970919 do tagdelete libc-970920 do tagdelete libc-970921 do tagdelete libc-970922 do tagdelete libc-970923 do tagdelete libc-970924 do tagdelete libc-970925 do tagdelete libc-970926 do tagdelete libc-970927 do tagdelete libc-970928 do tagdelete libc-970929 do tagdelete libc-970930 do tagdelete libc-971001 do tagdelete libc-971018 do tagdelete libc-971019 do tagdelete libc-971020 do tagdelete libc-971021 do tagdelete libc-971022 do tagdelete libc-971023 do tagdelete libc-971024 do tagdelete libc-971025 do tagdelete libc-971026 do tagdelete libc-971027 do tagdelete libc-971028 do tagdelete libc-971029 do tagdelete libc-971030 do tagdelete libc-971031 do tagdelete libc-971101 do tagdelete libc-971102 do tagdelete libc-971103 do tagdelete libc-971104 do tagdelete libc-971105 do tagdelete libc-971106 do tagdelete libc-971107 do tagdelete libc-971108 do tagdelete libc-971109 do tagdelete libc-971110 do tagdelete libc-971111 do tagdelete libc-971112 do tagdelete libc-971113 do tagdelete libc-971114 do tagdelete libc-971115 do tagdelete libc-971116 do tagdelete libc-971117 do tagdelete libc-971118 do tagdelete libc-971120 do tagdelete libc-971121 do tagdelete libc-971122 do tagdelete libc-971123 do tagdelete libc-971124 do tagdelete libc-971125 do tagdelete libc-971126 do tagdelete libc-971127 do tagdelete libc-971128 do tagdelete libc-971129 do tagdelete libc-971130 do tagdelete libc-971201 do tagdelete libc-971203 do tagdelete libc-971204 do tagdelete libc-971205 do tagdelete libc-971206 do tagdelete libc-971207 do tagdelete libc-971208 do tagdelete libc-971209 do tagdelete libc-971210 do tagdelete libc-971211 do tagdelete libc-971212 do tagdelete libc-971213 do tagdelete libc-971214 do tagdelete libc-971217 do tagdelete libc-971218 do tagdelete libc-971219 do tagdelete libc-971220 do tagdelete libc-971221 do tagdelete libc-971222 do tagdelete libc-971223 do tagdelete libc-971224 do tagdelete libc-971225 do tagdelete libc-971226 do tagdelete libc-971227 do tagdelete libc-971228 do tagdelete libc-971229 do tagdelete libc-971230 do tagdelete libc-971231 do tagdelete libc-980103 do tagdelete libc-980104 do tagdelete libc-980105 do tagdelete libc-980106 do tagdelete libc-980107 do tagdelete libc-980108 do tagdelete libc-980109 do tagdelete libc-980110 do tagdelete libc-980111 do tagdelete libc-980112 do tagdelete libc-980114 do tagdelete libc-980115 do tagdelete libc-980116 do tagdelete libc-980117 do tagdelete libc-980118 do tagdelete libc-980119 do tagdelete libc-980120 do tagdelete libc-980121 do tagdelete libc-980122 do tagdelete libc-980123 do tagdelete libc-980124 do tagdelete libc-980125 do tagdelete libc-980126 do tagdelete libc-980127 do tagdelete libc-980128 do tagdelete libc-980129 do tagdelete libc-980130 do tagdelete libc-980212 do tagdelete libc-980213 do tagdelete libc-980214 do tagdelete libc-980215 do tagdelete libc-980216 do tagdelete libc-980217 do tagdelete libc-980218 do tagdelete libc-980219 do tagdelete libc-980220 do tagdelete libc-980221 do tagdelete libc-980222 do tagdelete libc-980223 do tagdelete libc-980224 do tagdelete libc-980225 do tagdelete libc-980226 do tagdelete libc-980227 do tagdelete libc-980228 do tagdelete libc-980301 do tagdelete libc-980302 do tagdelete libc-980303 do tagdelete libc-980304 do tagdelete libc-980306 do tagdelete libc-980307 do tagdelete libc-980308 do tagdelete libc-980309 do tagdelete libc-980310 do tagdelete libc-980311 do tagdelete libc-980312 do tagdelete libc-980313 do tagdelete libc-980314 do tagdelete libc-980315 do tagdelete libc-980316 do tagdelete libc-980317 do tagdelete libc-980318 do tagdelete libc-980319 do tagdelete libc-980320 do tagdelete libc-980321 do tagdelete libc-980322 do tagdelete libc-980323 do tagdelete libc-980324 do tagdelete libc-980325 do tagdelete libc-980326 do tagdelete libc-980327 do tagdelete libc-980328 do tagdelete libc-980329 do tagdelete libc-980330 do tagdelete libc-980331 do tagdelete libc-980401 do tagdelete libc-980402 do tagdelete libc-980403 do tagdelete libc-980404 do tagdelete libc-980405 do tagdelete libc-980406 do tagdelete libc-980407 do tagdelete libc-980408 do tagdelete libc-980409 do tagdelete libc-980410 do tagdelete libc-980411 do tagdelete libc-980412 do tagdelete libc-980413 do tagdelete libc-980414 do tagdelete libc-980428 do tagdelete libc-980429 do tagdelete libc-980430 do tagdelete libc-980501 do tagdelete libc-980502 do tagdelete libc-980503 do tagdelete libc-980504 do tagdelete libc-980505 do tagdelete libc-980506 do tagdelete libc-980507 do tagdelete libc-980508 do tagdelete libc-980509 do tagdelete libc-980510 do tagdelete libc-980512 do tagdelete libc-980513 do tagdelete libc-980514 do tagdelete libc-980515 do tagdelete libc-980516 do tagdelete libc-980517 do tagdelete libc-980518 do tagdelete libc-980519 do tagdelete libc-980520 do tagdelete libc-980521 do tagdelete libc-980522 do tagdelete libc-980523 do tagdelete libc-980524 do tagdelete libc-980525 do tagdelete libc-980526 do tagdelete libc-980527 do tagdelete libc-980528 do tagdelete libc-980529 do tagdelete libc-980530 do tagdelete libc-980531 do tagdelete libc-980601 do tagdelete libc-980602 do tagdelete libc-980603 do tagdelete libc-980604 do tagdelete libc-980605 do tagdelete libc-980606 do tagdelete libc-980607 do tagdelete libc-980608 do tagdelete libc-980609 do tagdelete libc-980610 do tagdelete libc-980611 do tagdelete libc-980612 do tagdelete libc-980613 do tagdelete libc-980614 do tagdelete libc-980615 do tagdelete libc-980616 do tagdelete libc-980617 do tagdelete libc-980618 do tagdelete libc-980619 do tagdelete libc-980620 do tagdelete libc-980621 do tagdelete libc-980622 do tagdelete libc-980623 do tagdelete libc-980624 do tagdelete libc-980625 do tagdelete libc-980626 do tagdelete libc-980627 do tagdelete libc-980628 do tagdelete libc-980629 do tagdelete libc-980630 do tagdelete libc-980701 do tagdelete libc-980702 do tagdelete libc-980703 do tagdelete libc-980704 do tagdelete libc-980705 do tagdelete libc-980706 do tagdelete libc-980707 do tagdelete libc-980708 do tagdelete libc-980709 do tagdelete libc-980710 do tagdelete libc-980711 do tagdelete libc-980712 do tagdelete libc-980713 do tagdelete libc-980714 do tagdelete libc-980715 do tagdelete libc-980716 do tagdelete libc-980717 do tagdelete libc-980718 do tagdelete libc-980719 do tagdelete libc-980720 do tagdelete libc20x-970306 do tagdelete libc20x-97031 do tagdelete libc20x-970316 do tagdelete libc20x-970318 do tagdelete libc20x-970319 do tagdelete libc20x-970404 do tagdelete libc20x-970417 do tagdelete libc_1_09 do tagdelete lisp-bob do tagdelete make-3-72-10 do tagdelete make-3-72-11 do tagdelete make-3-72-12 do tagdelete make-3-72-13 do tagdelete make-3-72-9 do tagdelete make-3-73 do tagdelete make-3-73-1 do tagdelete make-3-73-2 do tagdelete make-3-73-3 do tagdelete make-3-74 do tagdelete make-3-74-1 do tagdelete make-3-74-2 do tagdelete make-3-74-3 do tagdelete make-3-74-4 do tagdelete make-3-74-5 do tagdelete make-3-74-6 do tagdelete make-3-74-7 do tagdelete make-3-75 do tagdelete make-3-75-1 do tagdelete make-3-75-91 do tagdelete make-3-75-92 do tagdelete make-3-75-93 do tagdelete make-3-76 do tagdelete make-3-76-1 do tagdelete make-3-77 do tagdelete merge-multi-tty-to-trunk do tagdelete merge-unicode-to-trunk do tagdelete mh-e-7_85 do tagdelete mh-e-7_90 do tagdelete mh-e-7_91 do tagdelete mh-e-7_92 do tagdelete mh-e-7_93 do tagdelete mh-e-7_94 do tagdelete mh-e-7_95 do tagdelete mh-e-8.2.90 do tagdelete mh-e-8.2.91 do tagdelete mh-e-8.2.92 do tagdelete mh-e-8.2.93 do tagdelete mh-e-8.3 ##do tagdelete mh-e-8.3.1 do tagdelete mh-e-8.4 do tagdelete mh-e-8.5 do tagdelete mh-e-8_0 do tagdelete mh-e-8_0_1 do tagdelete mh-e-8_0_2 do tagdelete mh-e-8_0_3 do tagdelete mh-e-8_1 do tagdelete mh-e-8_2 do tagdelete mh-e-doc-7_94 do tagdelete mh-e-doc-8.3 do tagdelete mh-e-doc-8.4 do tagdelete mh-e-doc-8.5 do tagdelete mh-e-doc-8_0 do tagdelete mh-e-doc-8_0_1 do tagdelete mh-e-doc-8_0_3 do tagdelete mh-e-doc-8_1 do tagdelete mh-e-doc-8_2 do tagdelete multi-tty-base ##do tagdelete patches_21_0_base do tagdelete raeburn-tag-4-for-export do tagdelete raeburn-tag-5-for-export do tagdelete raeburn-tag-6-for-export do tagdelete raeburn-tag-7-for-export do tagdelete release-0-0 do tagdelete release-0-1 do tagdelete release-1-0 do tagdelete remove-carbon do tagdelete remove-vms do tagdelete root-libc-2_0_x-branch do tagdelete small-dump-base do tagdelete sml-mode-6.0 do tagdelete sml-mode-6.1 do tagdelete tmp_pcl_tag_131034C # keep ttn-vms-21-2-B2 # keep ttn-vms-21-2-B3 # keep ttn-vms-21-2-B4 do tagdelete unicode-post-font-backend do tagdelete unicode-pre-font-backend do tagdelete unicode-xft-base do tagdelete v0.1 do tagdelete v0.1.0 do tagdelete v0.1.1 do tagdelete v0.1.2 do tagdelete v0.1.3 do tagdelete v0.2.0 do tagdelete v0.3.0 do tagdelete v1_7i do tagdelete v2007-Sep-10 do tagdelete xwidget-0.2 do tagdelete zsh-merge-ognus-1 do tagdelete zsh-sync-ognus-2 do tagdelete zsh-sync-ognus-3 undefine tagdelete undefine tagrename # # These look like branches but are just obsolete tags # tag delete remotes/origin/other-branches/gerd_0001 tag delete remotes/origin/other-branches/gerd_int tag delete remotes/origin/other-branches/miles-orphaned-changes tag delete remotes/origin/old-branches/pending # # There are a number of branches that are (incorrectly) labeled # as remotes even after having been merged, for hysterical raisins. Fix this. # define deremote tag remotes/origin/{0} rename {0} do deremote emacs23 do deremote emacs24 do deremote cedet-branch do deremote emacs-unicode do deremote gerd-defvaralias do deremote gnus-5_10-branch do deremote lexbind-new do deremote multi-tty do deremote pending do deremote profiler do deremote python do deremote rmail-mbox-branch do deremote pending undefine deremote # # Prune obsolete branches # branch delete origin/old-branches/elpa # # Fix up fossil references in ChangeLogs # It's OK if this list isn't quite complete yet, fixing up most # references will make the unmatched ones stick out like sore thumbs. # # Some known defects and false matches: # 1. revisions 1.59 and 1.61 of TUTORIAL can no longer be identified # in the RCS - likely because of a file move # 2. "cvs-1.12.1" is not a reference to a CVS revision, rather it's # reference to a revision of CVS. # # The instances of (?![0-9]) prevent false matches on prefixes of # a Bazaar or CVS revision. define changelog =B & [/ChangeLog/] filter --replace /{0}(?![0-9])/{1}/ define changecomment =C filter --replace /{0}(?![0-9])/{1}/ do changelog "100984" "2010-08-05T23:34:12Z!dann@ics.uci.edu" do changelog "101422" "2010-09-13T15:17:01Z!michael.albinus@gmx.de" do changelog "103083" "2011-02-02T17:59:44Z!sds@gnu.org" do changelog "107149" "2012-02-06T22:08:41Z!larsi@gnus.org" do changelog "109621" "2012-08-15T03:33:55Z!monnier@iro.umontreal.ca" do changelog "2010-07-29 (revno 100939)" "2010-07-29T16:49:59Z!jan.h.d@swipnet.se" do changelog "2011-04-26 change (bzr 104015)" "2011-04-26T11:26:05Z!dan.colascione@gmail.com" do changelog "2011-08-30 (revision 105619)" "2011-08-30T17:32:44Z!eliz@gnu.org" do changelog "2011-08-30 (revision 105619)" "2011-08-30T17:32:44Z!eliz@gnu.org" do changelog "2013-12-11 (r115470)" "2013-12-11T19:01:44Z!tzz@lifelogs.com" do changelog "Revision 1\.694" "2004-05-20T23:29:24Z!teirllm@auburn.edu" do changelog "erc\.el 1\.39" "2007-12-01T03:41:01Z!rgm@gnu.org" do changelog "of 2012-12-20 (r111276)" "2012-12-20T11:15:38Z!michael.albinus@gmx.de" do changelog "r112148" "2013-03-26T22:08:58Z!aidalgol@no8wireless.co.nz" do changelog "r114834" "2013-10-29T02:50:24Z!dancol@dancol.org" do changelog "r115470" "2013-12-11T19:01:44Z!tzz@lifelogs.com" do changelog "r99212" "2009-12-29T07:22:00Z!nickrob@snap.net.nz" do changelog "rev 1\.82" "1994-08-03T07:39:00Z!rms@gnu.org" do changelog "rev 100010" "2010-04-23T16:26:11Z!monnier@iro.umontreal.ca" do changelog "rev 102609" "2010-12-08T08:09:27Z!kfogel@red-bean.com" do changelog "rev\. 110325" "2012-10-01T18:10:29Z!cyd@gnu.org" do changelog "rev\. 110325" "2012-10-01T18:10:29Z!cyd@gnu.org" do changelog "revision 1\.1" "the initial version" do changelog "revision 1\.104, made on 2000-05-21" "2000-05-21T17:04:47Z!fx@gnu.org" do changelog "revision 1\.117" "2008-10-29T17:42:49Z!cyd@stupidchicken.com" do changelog "revision 1\.30 of saveplace\.el" "saveplace.el at 2005-04-10T23:32:00Z!rms@gnu.org" do changelog "revision 1\.32 of saveplace\.el" "saveplace.el at 2005-05-29T08:36:26Z!rms@gnu.org" do changelog "revision 1\.90 (commitid mWoPbju3pgNotDps)" "2007-07-13T18:16:17Z!kfogel@red-bean.com" do changelog "revision 104134" "2011-05-06T07:13:19Z!eggert@cs.ucla.edu" do changelog "revision 104625" "2011-06-18T18:49:19Z!cyd@stupidchicken.com" do changelog "revision 106664" "2011-12-11T14:49:48Z!vincentb1@users.sourceforge.net" do changelog "revision 106831" "2012-01-10T08:27:22Z!cyd@gnu.org" do changelog "revision 114614 (commit of 2013-10-10)" "2013-10-10T19:15:33Z!eggert@cs.ucla.edu" do changelog "revision 84777 on 2008-02-22" "2008-02-22T17:42:09Z!monnier@iro.umontreal.ca" do changelog "revno 100306" "2010-05-15T21:21:30Z!raeburn@raeburn.org" do changelog "revno 100789" "2010-07-12T05:26:57Z!handa@etlken" do changelog "revno 100928" "2010-07-29T03:25:08Z!dann@ics.uci.edu" do changelog "revno 101459" "2010-09-17T13:30:30Z!monnier@iro.umontreal.ca" do changelog "revno 101688" "2010-09-30T02:53:26Z!lekktu@gmail.com" do changelog "revno 101757" "2010-10-03T13:59:56Z!dann@ics.uci.edu" do changelog "revno 101876" "2010-10-09T18:31:12Z!rgm@gnu.org" do changelog "revno 101897" "2010-10-10T14:43:05Z!dann@ics.uci.edu" do changelog "revno 101949" "2010-10-13T14:50:06Z!lekktu@gmail.com" do changelog "revno 103623" "2011-03-11T07:24:21Z!eggert@cs.ucla.edu" do changelog "revno 108687" "2012-06-22T21:17:42Z!eggert@cs.ucla.edu" do changelog "revno 108687" "2012-06-22T21:17:42Z!eggert@cs.ucla.edu" do changelog "revno 108687" "2012-06-22T21:17:42Z!eggert@cs.ucla.edu" do changelog "revno 82799 (2007-11-30)" "2007-11-30T13:57:21Z!jasonr@gnu.org" do changelog "revno 95090 dated 2009-03-06" "2009-03-06T07:51:52Z!handa@m17n.org" do changelog "revno 99854\.1\.6" "2010-04-17T12:33:05Z!eliz@gnu.org" do changelog "revno 99950" "2010-04-20T13:31:28Z!eliz@gnu.org" do changelog "revno r112320" "2013-04-18T00:12:33Z!monnier@iro.umontreal.ca" do changelog "revno:100708" "2010-07-04T07:50:25Z!dann@ics.uci.edu" do changelog "revno:101730 (2010-10-02)" "2010-10-02T13:21:43Z!michael.albinus@gmx.de" do changelog "revno:101913" "2010-10-11T23:57:49Z!lekktu@gmail.com" do changelog "revno:102982 (2011-01-26)" "2011-01-26T20:02:07Z!monnier@iro.umontreal.ca" do changelog "revno:103013" "2011-01-28T22:12:05Z!monnier@iro.umontreal.ca" do changelog "revno:103877 (2011-04-09)" "2011-04-09T20:28:01Z!cyd@stupidchicken.com" do changelog "revno:104787 (2011-06-30)" "2011-06-30T01:09:13Z!larsi@gnus.org" do changelog "revno:104988 (2011-07-06)" "2011-07-06T15:49:19Z!larsi@gnus.org" do changelog "revno:105007" "2011-07-07T04:21:49Z!handa@m17n.org" do changelog "revno:105285" "2011-07-19T15:01:49Z!larsi@gnus.org" do changelog "revno:106608" "2011-12-04T17:13:01Z!lekktu@gmail.com" do changelog "revno:108341" "2012-05-22T16:20:27Z!eggert@cs.ucla.edu" do changelog "revno:108521" "2012-06-08T08:44:45Z!eliz@gnu.org" do changelog "revno:108936" "2012-07-07T10:34:37Z!cyd@gnu.org" do changelog "revno:109911" "2012-09-07T04:15:56Z!dgutov@yandex.ru" do changelog "revno:110851" "2012-11-09T04:10:16Z!monnier@iro.umontreal.ca" do changelog "revno:113117" "2013-06-21T12:24:37Z!lekktu@gmail.com" do changelog "revno:113147" "2013-06-23T20:29:18Z!lekktu@gmail.com" do changelog "revno:113431" "2013-07-16T11:41:06Z!jan.h.d@swipnet.se" do changelog "revno:113431" "2013-07-16T11:41:06Z!jan.h.d@swipnet.se" do changelog "revno:113793" "2013-08-11T00:07:48Z!lekktu@gmail.com" do changelog "revno:114543" "2013-10-07T01:28:34Z!sdl.web@gmail.com" do changelog "revno:14998 (1996-04-12)" "1996-04-12T06:01:29Z!rms@gnu.org" do changelog "revno:20537 (1998-01-01)" "1998-01-01T02:27:27Z!rms@gnu.org" do changelog "revno:20537 (1998-01-01)" "1998-01-01T02:27:27Z!rms@gnu.org" do changelog "revno:20569 (1998-01-02)" "1998-01-02T21:29:48Z!rms@gnu.org" do changelog "revno:20870 (1998-02-08)" "1998-02-08T21:33:56Z!rms@gnu.org" do changelog "revno:25013 (1999-07-21)" "1999-07-21T21:43:52Z!gerd@gnu.org" do changelog "revno:25013 (1999-07-21)" "1999-07-21T21:43:52Z!gerd@gnu.org" do changelog "revno:25356 (1999-08-21)" "1999-08-21T19:30:21Z!gerd@gnu.org" do changelog "revno:32591 (2000-10-17)" "2000-10-17T16:08:18Z!gerd@gnu.org" do changelog "revno:34925 (2000-12-29)" "2000-12-29T14:24:09Z!gerd@gnu.org" do changelog "revno:36704 (2001-03-09)" "2001-03-09T18:41:50Z!gerd@gnu.org" do changelog "revno:43563\.1\.17 (2002-03-01)" "2002-03-01T01:17:24Z!handa@m17n.org" do changelog "revno:43563\.1\.32 (2002-03-01)" "2002-03-01T01:17:24Z!handa@m17n.org" do changelog "revno:50135 (2003-03-16)" "2003-03-16T20:45:46Z!storm@cua.dk" do changelog "revno:84043 (2008-02-1)" "2008-02-01T16:01:31Z!miles@gnu.org" do changelog "revno:86854 (2008-04-19)" "2008-04-19T19:30:53Z!monnier@iro.umontreal.ca" do changelog "revno:87605 (2008-05-14)" "2008-05-14T01:40:23Z!handa@m17n.org" do changelog "revno:87605 (2008-05-14)" "2008-05-14T01:40:23Z!handa@m17n.org" do changelog "revno:88805" "2008-06-21T01:38:39Z!monnier@iro.umontreal.ca" do changelog "revno:88864" "2008-06-22T13:57:28Z!monnier@iro.umontreal.ca" do changelog "revno:89810" "2008-07-31T05:33:56Z!dann@ics.uci.edu" do changelog "revno:99634\.2\.463 (2010-10-09)" "2010-10-09T04:09:19Z!cyd@stupidchicken.com" do changelog "revno\n103471" "\n2011-03-02T03:48:01Z!cyd@stupidchicken.com" do changelog "revnos 100982" "2010-08-05T23:15:24Z!dann@ics.uci.edu" do changelog "revnos 101381" "2010-09-08T14:42:54Z!michael.albinus@gmx.de" do changelog "the 2011-04-14 change (bzr 103913)" "2011-04-14T23:19:38Z!eggert@cs.ucla.edu" do changelog "version 1\.100" "2007-12-06T19:56:41Z!deego@gnufans.org" do changelog "revision 1\.59" "CVS revision 1.59" do changecomment "1\.39" "2007-12-01T03:41:01Z!rgm@gnu.org" do changecomment "103071" "2011-02-01T18:15:18Z!sds@gnu.org" do changecomment "103199" "2011-02-09T17:04:43Z!schwab@linux-m68k.org" do changecomment "106124" "2011-10-18T16:56:09Z!eliz@gnu.org" do changecomment "108099" "2012-05-02T11:38:01Z!lekktu@gmail.com" do changecomment "109252" "2012-07-28T23:05:32Z!eggert@cs.ucla.edu" do changecomment "109542" "2012-08-10T06:54:37Z!eliz@gnu.org" do changecomment "109766" "2012-08-25T04:27:32Z!eggert@cs.ucla.edu" do changecomment "111840" "2013-02-21T02:42:30Z!eggert@cs.ucla.edu" do changecomment "114527" "2013-10-05T02:26:39Z!dgutov@yandex.ru" do changecomment "2005-02-15 (revno 60055)" "2005-02-15T23:19:26Z!jasonr@gnu.org" do changecomment "2011-04-26 change (bzr 104015)" "2011-04-26T11:26:05Z!dan.colascione@gmail.com" do changecomment "2011-08-30 (revision 105619)" "2011-08-30T17:32:44Z!eliz@gnu.org" do changecomment "bzrs 111300" "2012-12-22T19:57:35Z!rgm@gnu.org" do changecomment "change 103083" "2011-02-02T17:59:44Z!sds@gnu.org" do changecomment "commit 115961" "2014-01-10T12:41:19Z!ruediger@c-plusplus.de" do changecomment "patch 99592" "2010-03-01T11:31:42Z!acm@muc.de" do changecomment "r1\.135" "2009-10-10T21:48:22Z!kfogel@red-bean.com" do changecomment "r100577" "2010-06-10T12:56:11Z!michael.albinus@gmx.de" do changecomment "r111320" "2012-12-24T15:56:17Z!eliz@gnu.org" do changecomment "rev 1\.82" "1994-08-03T07:39:00Z!rms@gnu.org" do changecomment "rev 100010" "2010-04-23T16:26:11Z!monnier@iro.umontreal.ca" do changecomment "rev 102609" "2010-12-08T08:09:27Z!kfogel@red-bean.com" do changecomment "rev 109972" "2012-09-10T21:01:45Z!jan.h.d@swipnet.se" do changecomment "rev 110325" "2012-10-01T18:10:29Z!cyd@gnu.org" do changecomment "rev 99553" "2010-02-24T22:07:26Z!bob@gnu.org" do changecomment "rev 99649" "2010-03-12T16:34:27Z!eliz@gnu.org" do changecomment "revision 1\.1" "initial revision" do changecomment "revision 1\.117" "2008-10-29T17:42:49Z!cyd@stupidchicken.com" do changecomment "revision 1\.30" "2005-04-10T23:32:00Z!rms@gnu.org" do changecomment "revision 1\.32" "2005-05-29T08:36:26Z!rms@gnu.org" do changecomment "revision 1\.90 (commitid mWoPbju3pgNotDps)" "2007-07-13T18:16:17Z!kfogel@red-bean.com" do changecomment "revision 102407" "2010-11-16T19:59:24Z!cyd@stupidchicken.com" do changecomment "revision 102572" "2010-12-03T11:52:43Z!yamaoka@jpl.org" do changecomment "revision 103104" "2011-02-03T19:30:24Z!eggert@cs.ucla.edu" do changecomment "revision 103365" "2011-02-20T18:50:26Z!eliz@gnu.org" do changecomment "revision 103378" "2011-02-22T00:15:53Z!eggert@cs.ucla.edu" do changecomment "revision 103558" "2011-03-06T08:31:32Z!eggert@cs.ucla.edu" do changecomment "revision 103643" "2011-03-13T06:43:00Z!eggert@cs.ucla.edu" do changecomment "revision 103792" "2011-03-31T19:12:30Z!eliz@gnu.org" do changecomment "revision 103798" "2011-04-01T17:19:52Z!monnier@iro.umontreal.ca" do changecomment "revision 103841" "2011-04-06T05:19:39Z!eggert@cs.ucla.edu" do changecomment "revision 104264" "2011-05-18T00:35:01Z!eggert@cs.ucla.edu" do changecomment "revision 104265" "2011-05-18T00:52:24Z!eggert@cs.ucla.edu" do changecomment "revision 104320" "2011-05-22T19:46:47Z!cyd@stupidchicken.com" do changecomment "revision 104551" "2011-06-10T06:55:18Z!rudalics@gmx.at" do changecomment "revision 106131" "2011-10-19T09:48:35Z!eliz@gnu.org" do changecomment "revision 106293" "2011-11-05T12:04:34Z!jan.h.d@swipnet.se" do changecomment "revision 106664" "2011-12-11T14:49:48Z!vincentb1@users.sourceforge.net" do changecomment "revision 106726" "2011-12-23T14:51:51Z!eliz@gnu.org" do changecomment "revision 106726" "2011-12-23T14:51:51Z!eliz@gnu.org" do changecomment "revision 106798" "2012-01-06T08:10:22Z!rgm@gnu.org" do changecomment "revision 106831" "2012-01-10T08:27:22Z!cyd@gnu.org" do changecomment "revision 108149" "2012-05-07T20:48:41Z!monnier@iro.umontreal.ca" do changecomment "revision 10835" "1995-02-25T20:57:45Z!rms@gnu.org" do changecomment "revision 108801" "2012-06-29T11:48:08Z!dmantipov@yandex.ru" do changecomment "revision 109685" "2012-08-19T21:00:09Z!eggert@cs.ucla.edu" do changecomment "revision 109836" "2012-09-01T08:01:36Z!dancol@dancol.org" do changecomment "revision 109909" "2012-09-07T01:27:44Z!eggert@cs.ucla.edu" do changecomment "revision 110152" "2012-09-23T08:44:20Z!eggert@cs.ucla.edu" do changecomment "revision 110608" "2012-10-21T01:19:46Z!rgm@gnu.org" do changecomment "revision 110889" "2012-11-14T04:55:41Z!eggert@cs.ucla.edu" do changecomment "revision 111151" "2012-12-08T02:30:51Z!eggert@cs.ucla.edu" do changecomment "revision 111602" "2013-01-25T10:27:16Z!eliz@gnu.org" do changecomment "revision 111647" "2013-02-01T07:23:18Z!dmantipov@yandex.ru" do changecomment "revision 112072" "2013-03-18T04:30:20Z!eggert@cs.ucla.edu" do changecomment "revision 113315" "2013-07-07T18:00:14Z!eggert@cs.ucla.edu" do changecomment "revision 115838" "2014-01-02T21:05:34Z!vincentb1@users.sourceforge.net" do changecomment "revision 115841" "2014-01-02T22:54:37Z!vincentb1@users.sourceforge.net" do changecomment "revision 84777 on 2008-02-22" "2008-02-22T17:42:09Z!monnier@iro.umontreal.ca" do changecomment "revision 87208" "2008-05-02T07:12:59Z!esr@snark.thyrsus.com" do changecomment "revision 94343" "2009-01-30T13:06:07Z!lekktu@gmail.com" do changecomment "revision 99649" "2010-03-12T16:34:27Z!eliz@gnu.org" do changecomment "revisions 103189" "2011-02-08T21:42:56Z!tromey@redhat.com" do changecomment "revisions 109765" "2012-08-25T04:04:08Z!eggert@cs.ucla.edu" do changecomment "revno 95090 dated 2009-03-06" "2009-03-06T07:51:52Z!handa@m17n.org" do changecomment "revno 99212" "2009-12-29T07:22:00Z!nickrob@snap.net.nz" do changecomment "revno 99854\.1\.6" "2010-04-17T12:33:05Z!eliz@gnu.org" do changecomment "revno 99950" "2010-04-20T13:31:28Z!eliz@gnu.org" do changecomment "revno:101913 (2010-10-12)\." "2010-10-11T23:57:49Z!lekktu@gmail.com" do changecomment "revno:11026" "1995-03-15T21:55:37Z!kwzh@gnu.org" do changecomment "revno:14998 (1996-04-12)" "1996-04-12T06:01:29Z!rms@gnu.org" do changecomment "revno:20537 (1998-01-01)" "1998-01-01T02:27:27Z!rms@gnu.org" do changecomment "revno:20537 (1998-01-01)" "1998-01-01T02:27:27Z!rms@gnu.org" do changecomment "revno:20569 (1998-01-02)" "1998-01-02T21:29:48Z!rms@gnu.org" do changecomment "revno:20870 (1998-02-08)" "1998-02-08T21:33:56Z!rms@gnu.org" do changecomment "revno:25013 (1999-07-21)" "1999-07-21T21:43:52Z!gerd@gnu.org" do changecomment "revno:25356 (1999-08-21)" "1999-08-21T19:30:21Z!gerd@gnu.org" do changecomment "revno:32591 (2000-10-17)" "2000-10-17T16:08:18Z!gerd@gnu.org" do changecomment "revno:34925 (2000-12-29)" "2000-12-29T14:24:09Z!gerd@gnu.org" do changecomment "revno:36704 (2001-03-09)" "2001-03-09T18:41:50Z!gerd@gnu.org" do changecomment "revno:43563\.1\.16 (2002-03-01)" "2002-03-01T01:16:34Z!handa@m17n.org" do changecomment "revno:84043 (2008-02-1)" "2008-02-01T16:01:31Z!miles@gnu.org" do changecomment "revno:86854 (2008-04-19)" "2008-04-19T19:30:53Z!monnier@iro.umontreal.ca" do changecomment "revno:87605 (2008-05-14)" "2008-05-14T01:40:23Z!handa@m17n.org" do changecomment "revno:87605 (2008-05-14)" "2008-05-14T01:40:23Z!handa@m17n.org" do changecomment "revno:88805" "2008-06-21T01:38:39Z!monnier@iro.umontreal.ca" do changecomment "revno:88864" "2008-06-22T13:57:28Z!monnier@iro.umontreal.ca" do changecomment "revno:89810" "2008-07-31T05:33:56Z!dann@ics.uci.edu" do changecomment "revno:99634\.2\.463 (2010-10-09)" "2010-10-09T04:09:19Z!cyd@stupidchicken.com" do changecomment "the 2011-04-14 change (bzr 103913)" "2011-04-14T23:19:38Z!eggert@cs.ucla.edu" do changecomment "version 1\.100" "2007-12-06T19:56:41Z!deego@gnufans.org" undefine changelog undefine changecomment # # Fix up ignore files # # Remove every .cvsignore not older than when .gitignores were # first added. Then rename all remaining (older) .cvsignores to # corresponding .gitignore paths; the syntax is upward-compatible. # The date marks the introduction of .gitignore files. # <2009-02-03T23:32:38Z>..$ & [/.cvsignore/] expunge path (.*)/.cvsignore rename \1/.gitignore # # Then treat .bzrignore files as authoritative, after changing leading # "./" to "/". (The only other syntax incompatibility is "RE:", which # the Emacs repository never uses.) The date marks the introduction of # .bzrignore files. # <2009-12-27T21:38:14Z>..$ & [/.gitignore/] expunge filter [\.bzrignore] filter --regex :^./:/: path (.*)/.bzrignore rename \1/.gitignore -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-30 19:55 Repo cpnversion progress report Eric S. Raymond @ 2014-01-30 20:11 ` Andreas Schwab 2014-01-30 20:27 ` Eric S. Raymond 2014-01-30 21:23 ` Eli Zaretskii 1 sibling, 1 reply; 38+ messages in thread From: Andreas Schwab @ 2014-01-30 20:11 UTC (permalink / raw) To: esr; +Cc: emacs-devel "Eric S. Raymond" <esr@thyrsus.com> writes: > tag delete remotes/origin/other-branches/gerd_0001 I think you should be operating on a mirror where there is no refs/remotes. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-30 20:11 ` Andreas Schwab @ 2014-01-30 20:27 ` Eric S. Raymond 2014-01-30 22:04 ` Andreas Schwab 0 siblings, 1 reply; 38+ messages in thread From: Eric S. Raymond @ 2014-01-30 20:27 UTC (permalink / raw) To: Andreas Schwab; +Cc: emacs-devel Andreas Schwab <schwab@linux-m68k.org>: > "Eric S. Raymond" <esr@thyrsus.com> writes: > > > tag delete remotes/origin/other-branches/gerd_0001 > > I think you should be operating on a mirror where there is no > refs/remotes. I'm operating on a pull of the git mirror. Can you be more explicit about what you think I should be doing instead? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-30 20:27 ` Eric S. Raymond @ 2014-01-30 22:04 ` Andreas Schwab 0 siblings, 0 replies; 38+ messages in thread From: Andreas Schwab @ 2014-01-30 22:04 UTC (permalink / raw) To: esr; +Cc: emacs-devel "Eric S. Raymond" <esr@thyrsus.com> writes: > I'm operating on a pull of the git mirror. Can you be more > explicit about what you think I should be doing instead? git clone --mirror Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-30 19:55 Repo cpnversion progress report Eric S. Raymond 2014-01-30 20:11 ` Andreas Schwab @ 2014-01-30 21:23 ` Eli Zaretskii 2014-01-30 21:42 ` Eric S. Raymond 1 sibling, 1 reply; 38+ messages in thread From: Eli Zaretskii @ 2014-01-30 21:23 UTC (permalink / raw) To: esr; +Cc: emacs-devel > Date: Thu, 30 Jan 2014 14:55:57 -0500 > From: "Eric S. Raymond" <esr@thyrsus.com> > > The current version of the reposurgeon conversion script follows. The > header comment explains the major steps. Most can be sanity-checked > by eyeball and a little investigation with git log or gitk; interested > parties are invited to do so. The list of bzr revisions in changecomment lines is still too short, about one third of the real list. Also, it looks like you are going to _replace_ the revision numbers with the time stamp, not just _add_ the time stamp? If so, I strongly suggest to leave the revision numbers intact, so that we don't lose information. > # Fix up ignore files > # > # Remove every .cvsignore not older than when .gitignores were > # first added. Then rename all remaining (older) .cvsignores to > # corresponding .gitignore paths; the syntax is upward-compatible. > # The date marks the introduction of .gitignore files. This looks gratuitous and loses information. I think you shouldn't be doing that. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-30 21:23 ` Eli Zaretskii @ 2014-01-30 21:42 ` Eric S. Raymond 2014-01-31 7:50 ` Eli Zaretskii 0 siblings, 1 reply; 38+ messages in thread From: Eric S. Raymond @ 2014-01-30 21:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org>: > The list of bzr revisions in changecomment lines is still too short, > about one third of the real list. I went through the putput of bzr log --levels 0 with grep and eyeball last night; those are what I found. It would be helpful if you were to supply what you think of as the real list. > Also, it looks like you are going to _replace_ the revision numbers > with the time stamp, not just _add_ the time stamp? If so, I strongly > suggest to leave the revision numbers intact, so that we don't lose > information. After we change over, the Bazaar revision numbers will be meaningless except as keys to a map file which is just going to associate them with the action stamps I'm replacing them with. Please explain what information you think is being lost here, because I don't get it. > > # Remove every .cvsignore not older than when .gitignores were > > # first added. Then rename all remaining (older) .cvsignores to > > # corresponding .gitignore paths; the syntax is upward-compatible. > > # The date marks the introduction of .gitignore files. > > This looks gratuitous and loses information. I think you shouldn't be > doing that. What would you do instead? What information do you believe the newer .cvsignores carry that the .bzrignores and .gitignores do not? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-30 21:42 ` Eric S. Raymond @ 2014-01-31 7:50 ` Eli Zaretskii 2014-01-31 15:25 ` Eric S. Raymond 2014-01-31 17:31 ` Karl Fogel 0 siblings, 2 replies; 38+ messages in thread From: Eli Zaretskii @ 2014-01-31 7:50 UTC (permalink / raw) To: esr; +Cc: emacs-devel > Date: Thu, 30 Jan 2014 16:42:01 -0500 > From: "Eric S. Raymond" <esr@thyrsus.com> > Cc: emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org>: > > The list of bzr revisions in changecomment lines is still too short, > > about one third of the real list. > > I went through the putput of bzr log --levels 0 with grep and eyeball > last night; those are what I found. What grep command did you use? The regexp(s) you gave to grep are the key. I use "bzr log" with multiple --match-message options (they accept Python regexps), which is similar. So the difference must come from the regular expressions used. > It would be helpful if you were to supply what you think of as the > real list. I'm sorry, but my motivation to help you at this point is nil, I'm sure you understand why. I even needed to debate whether to point out that you had a very incomplete list of references. > > Also, it looks like you are going to _replace_ the revision numbers > > with the time stamp, not just _add_ the time stamp? If so, I strongly > > suggest to leave the revision numbers intact, so that we don't lose > > information. > > After we change over, the Bazaar revision numbers will be meaningless > except as keys to a map file which is just going to associate them > with the action stamps I'm replacing them with. They are not meaningless, since, as you correctly recommend, the bzr repo should be kept frozen at the point of the switch, rather than deleted. If something goes wrong during the conversion, and someone needs to do some archeology later, these numbers might help. So I suggest to make the replacements like this: "rev 102609" => "2010-12-08T08:09:27Z!kfogel@red-bean.com (bzr r102609)" ^^^^^^^^^^^^^ > > > # Remove every .cvsignore not older than when .gitignores were > > > # first added. Then rename all remaining (older) .cvsignores to > > > # corresponding .gitignore paths; the syntax is upward-compatible. > > > # The date marks the introduction of .gitignore files. > > > > This looks gratuitous and loses information. I think you shouldn't be > > doing that. > > What would you do instead? What information do you believe the newer > .cvsignores carry that the .bzrignores and .gitignores do not? I see no need to remove files that existed at a certain date, as that changes history for no good reason. We have no idea whether .gitignores and .bzrignores were indeed 100% equivalent to .cvsignores (it's humans who did that job, and they are prone to errors). I certainly see no reason for this part: Then rename all remaining (older) .cvsignores to corresponding .gitignore paths; the syntax is upward-compatible. This doesn't make sense at all to me: would you also rename a .c file to a .el file if it was at some later point rewritten in Lisp? If I checkout a revision from 1990, I don't want to see a .gitignore file that didn't exist, and I certainly _do_ want to see a .cvsignore that did. The .*ignore files are here to make the display of status command cleaner, that's all. When I checkout an old revision, I don't need that feature, because I'm not going to commit from that point. So I don't see what is the motivation for this history rewrite in the first place. What do we gain from that? ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 7:50 ` Eli Zaretskii @ 2014-01-31 15:25 ` Eric S. Raymond 2014-01-31 15:57 ` David Kastrup 2014-01-31 16:15 ` Eli Zaretskii 2014-01-31 17:31 ` Karl Fogel 1 sibling, 2 replies; 38+ messages in thread From: Eric S. Raymond @ 2014-01-31 15:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org>: > I'm sorry, but my motivation to help you at this point is nil, I'm > sure you understand why. I'm sorry, but if you're not going to be helpful, then expect to be ignored. The cost of withdrawing any cooperation is that you lose influence over the result. You get to take what comes out the other end and like it. I'm not saying this out of personal rancor. This conversion job is so messy and labor-intensive that I simply cannot spare the energy to listen to people I think are just going to carp about it. Because I at least like to think I'm a reasonable person, you can rescue this situation at any time by displaying behavioral evidence of helpfulness. That means doing something concrete that helps the work along. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 15:25 ` Eric S. Raymond @ 2014-01-31 15:57 ` David Kastrup 2014-01-31 16:15 ` Eli Zaretskii 1 sibling, 0 replies; 38+ messages in thread From: David Kastrup @ 2014-01-31 15:57 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Eli Zaretskii, emacs-devel "Eric S. Raymond" <esr@thyrsus.com> writes: > Eli Zaretskii <eliz@gnu.org>: >> I'm sorry, but my motivation to help you at this point is nil, I'm >> sure you understand why. > > I'm sorry, but if you're not going to be helpful, then expect to be > ignored. The cost of withdrawing any cooperation is that you lose > influence over the result. You get to take what comes out the other > end and like it. I don't see any justification for the "and like it" angle. I also don't see any justification for the "you lose any influence" angle since that implies that voting for keeping the status quo is not an option. > I'm not saying this out of personal rancor. This conversion job is so > messy and labor-intensive that I simply cannot spare the energy to > listen to people I think are just going to carp about it. > > Because I at least like to think I'm a reasonable person, you can > rescue this situation at any time by displaying behavioral evidence of > helpfulness. That means doing something concrete that helps the work > along. There are certainly valid opinions about the cost/benefit of throwing the existing repository and all its references away that do not qualify as "doing something concrete that helps the work along". Putting a lot of work into a change does not automatically imply it has to be accepted. If you say that you are going to ignore any feedback that will distract you from finishing your work properly, that's a perfectly reasonable strategic decision. But the cost of that wager does not lie with Eli. A perfect pitch does not buy you a homerun (well, obviously). -- David Kastrup ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 15:25 ` Eric S. Raymond 2014-01-31 15:57 ` David Kastrup @ 2014-01-31 16:15 ` Eli Zaretskii 1 sibling, 0 replies; 38+ messages in thread From: Eli Zaretskii @ 2014-01-31 16:15 UTC (permalink / raw) To: esr; +Cc: emacs-devel > Date: Fri, 31 Jan 2014 10:25:18 -0500 > From: "Eric S. Raymond" <esr@thyrsus.com> > Cc: emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org>: > > I'm sorry, but my motivation to help you at this point is nil, I'm > > sure you understand why. > > I'm sorry, but if you're not going to be helpful, then expect to be > ignored. I'm ignored already. You never accepted any argument of mine through that long and tiresome "discussion". You are always right and all those who disagree with you are always wrong. > The cost of withdrawing any cooperation is that you lose influence > over the result. I never had any influence over that, because you refuse to listen to any dissenting arguments, and prefer to stubbornly do what you decided was right ahead of any discussion. > You get to take what comes out the other end and like it. Emacs is not my project, and this conversion is not my funeral. You may wish to stop being obsessed by my sorry self, and start seriously thinking of the greater good -- the good of the project with which you are messing. Because it's the project that will "take what comes out the other end", not me. > I'm not saying this out of personal rancor. This conversion job is so > messy and labor-intensive that I simply cannot spare the energy to > listen to people I think are just going to carp about it. You didn't listen to begin with. Look, you asked for comments on your progress report, and I gave them to you. It's up to you to act on those comments or ignore them. The results will speak for themselves. > Because I at least like to think I'm a reasonable person, you can > rescue this situation at any time by displaying behavioral evidence of > helpfulness. Thank you for this arrogant lecture, but I won't hold my breath if I were you, as I don't hold mine regarding a similar change in your behavior. > That means doing something concrete that helps the work along. I have no intention to help where my help is not welcome. If you want my help, you will need to accept and respect my judgments on what and how should or shouldn't be done, and at least sometimes agree or compromise. If instead you want to use me as a workhorse that just does as he is told and shuts up, you will have to look elsewhere. And I suggest all the others in this project to seriously consider whether we want to trust this job (or any job) to a man who thinks, speaks, and acts like you do. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 7:50 ` Eli Zaretskii 2014-01-31 15:25 ` Eric S. Raymond @ 2014-01-31 17:31 ` Karl Fogel 2014-01-31 17:56 ` Juanma Barranquero 2014-01-31 18:16 ` Eric S. Raymond 1 sibling, 2 replies; 38+ messages in thread From: Karl Fogel @ 2014-01-31 17:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >They are not meaningless, since, as you correctly recommend, the bzr >repo should be kept frozen at the point of the switch, rather than >deleted. If something goes wrong during the conversion, and someone >needs to do some archeology later, these numbers might help. > >So I suggest to make the replacements like this: > > "rev 102609" => "2010-12-08T08:09:27Z!kfogel@red-bean.com (bzr r102609)" > ^^^^^^^^^^^^^ I agree with Eli's point above, FWIW (and not just because he happened to use one of my (sadly rarer than I would like) commits as an example). Preserving the bzr revision number isn't very distracting -- anyone spelunking through this stuff already has good vgrep goggles on -- and provides a valuable trail in the event of an urgent forensic expedition. As we all know, such expeditions occur more often than we expect, even after we adjust our expectations accordingly :-). I don't agree with Eli's comments in a later mail about how he wasn't sure we should entrust this job to ESR. It's a complex, time-consuming, and apparently thankless task; IMHO ESR is doing a good job considering all the inputs involved (both human and machine). -K ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 17:31 ` Karl Fogel @ 2014-01-31 17:56 ` Juanma Barranquero 2014-01-31 19:23 ` Eric S. Raymond 2014-01-31 19:31 ` Karl Fogel 2014-01-31 18:16 ` Eric S. Raymond 1 sibling, 2 replies; 38+ messages in thread From: Juanma Barranquero @ 2014-01-31 17:56 UTC (permalink / raw) To: Karl Fogel; +Cc: Eric Raymond, Eli Zaretskii, Emacs developers On Fri, Jan 31, 2014 at 6:31 PM, Karl Fogel <kfogel@red-bean.com> wrote: > I don't agree with Eli's comments in a later mail about how he wasn't > sure we should entrust this job to ESR. It's a complex, time-consuming, > and apparently thankless task; IMHO ESR is doing a good job considering > all the inputs involved (both human and machine). Well, do you at least agree with him when he says > I'm ignored already. You never accepted any argument of mine through > that long and tiresome "discussion". You are always right and all > those who disagree with you are always wrong. and > I never had any influence over that, because you refuse to listen > to any dissenting arguments, and prefer to stubbornly do what you > decided was right ahead of any discussion. ? Because that's also my feeling about every single switching-to-git discussion we've had so far. The only thing Eric has backtracked about is the imminence of switching, and that because Stefan specifically said that it wouldn't happen during the freeze. J ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 17:56 ` Juanma Barranquero @ 2014-01-31 19:23 ` Eric S. Raymond 2014-01-31 19:55 ` Juanma Barranquero ` (4 more replies) 2014-01-31 19:31 ` Karl Fogel 1 sibling, 5 replies; 38+ messages in thread From: Eric S. Raymond @ 2014-01-31 19:23 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Karl Fogel, Eli Zaretskii, Emacs developers Juanma Barranquero <lekktu@gmail.com>: > Well, do you at least agree with him when he says > > > I'm ignored already. You never accepted any argument of mine through > > that long and tiresome "discussion". You are always right and all > > those who disagree with you are always wrong. > > and > > > I never had any influence over that, because you refuse to listen > > to any dissenting arguments, and prefer to stubbornly do what you > > decided was right ahead of any discussion. Sigh. I wasn't going to go there, but....in fact I have already done several work items raised specifically by Eli. And have several more remaining on the transition list. A notable one is ensuring that Bazaar "fixes bug" metadata is preserved, something not true of the mirror now. I'm a very reasonable person about meeting requirements like that which are raised in a genuine attempt to improve the quality of the result. It's for sure no one else is going to do them for you. Being reasonable does not, however, mean I will put up with obstreperous bullshit. What I just quoted, from Juanma and Eli both, was obstreperous bullshit. That, I respond to by decreasing my willingness to pay attention to the bullshitter. So let me spell it out: Juanma, if you think you are not being listened to, you have only your own bad attitude to blame for that. Same goes for you, Eli. After enough pissy, semi-autistic territorial grunting I just start tuning all of it out. Conversely, you can earn my attention and increased willingness to do what you want by putting effort into helping with the work. You can begin an attempt to be helpful at any time you like. Here are some things you could do to help: 1. Identify the actual merge points of as many of the =-prefixed attic files as possible, so I can do the cleanup Andreas wants. 2. Spot CVS cliques consisting of uncoalesced single-file changes and their ChangeLog entry commits so I can squash them into proper changesets. 3. Investigate the old-branches and other-branches groups and determine which ones, if any, should be dicarded. 4. Report Bazaar and CVS references that aren't already in the emacs.lift file. Or, you can leave me to do all the work alone while flaming from the sidelines. If you choose that, don't blame anyone but yourselves if you think (wrongly) that you've had no influence on the result. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 19:23 ` Eric S. Raymond @ 2014-01-31 19:55 ` Juanma Barranquero 2014-01-31 20:30 ` Eli Zaretskii ` (3 subsequent siblings) 4 siblings, 0 replies; 38+ messages in thread From: Juanma Barranquero @ 2014-01-31 19:55 UTC (permalink / raw) To: Eric Raymond; +Cc: Karl Fogel, Eli Zaretskii, Emacs developers On Fri, Jan 31, 2014 at 8:23 PM, Eric S. Raymond <esr@thyrsus.com> wrote: > What I just quoted, from Juanma and Eli both, > was obstreperous bullshit. Why settle for low-quality bullshit when we can do our best? > So let me spell it out: Juanma, if you think you are not being > listened to, you have only your own bad attitude to blame for that. I don't worry about being listened to by you, because the only discussion we've had, about your incompatible and ill-timed change to the bzr-version stuff, you already made perfectly clear that, as Eli has said, the only acceptable outcome was to acknowledge that you were right and I was wrong. After that I'm no longer interested in the git conversion. I don't help, and I don't interfere. Whatever will be, will be. But the rejection of your ways is not limited to Eli and me, not by a long shot. Just reread your interventions and the kind of answers it has triggered. Bad attitude indeed. J ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 19:23 ` Eric S. Raymond 2014-01-31 19:55 ` Juanma Barranquero @ 2014-01-31 20:30 ` Eli Zaretskii 2014-01-31 21:20 ` Sean Sieger ` (2 subsequent siblings) 4 siblings, 0 replies; 38+ messages in thread From: Eli Zaretskii @ 2014-01-31 20:30 UTC (permalink / raw) To: esr; +Cc: kfogel, lekktu, emacs-devel > Date: Fri, 31 Jan 2014 14:23:22 -0500 > From: "Eric S. Raymond" <esr@thyrsus.com> > Cc: Karl Fogel <kfogel@red-bean.com>, Eli Zaretskii <eliz@gnu.org>, > Emacs developers <emacs-devel@gnu.org> > > I'm a very reasonable person about meeting requirements like that > which are raised in a genuine attempt to improve the quality of the > result. Yeah, right. Of course, anything that you don't agree with is not a "genuine attempt to improve the quality", right? > Being reasonable does not, however, mean I will put up with > obstreperous bullshit. What I just quoted, from Juanma and Eli both, > was obstreperous bullshit. That, I respond to by decreasing my > willingness to pay attention to the bullshitter. I guess profanities is the only defense you have left. That's just pathetic. > Conversely, you can earn my attention and increased willingness to do > what you want by putting effort into helping with the work. You can > begin an attempt to be helpful at any time you like. What you are missing is that I already tried, and in response you publicly and viciously drew me away, just a couple of hours ago. > Or, you can leave me to do all the work alone while flaming from the > sidelines. If you choose that, don't blame anyone but yourselves > if you think (wrongly) that you've had no influence on the result. No one is flaming you. You are being pointed to the quality of your work, which so far is inadequate. You are also requested to do this job as this project's members feel you should. If you really want to help this project, you should listen. Instead, _you_ are flaming _us_, something that is entirely incompatible with a wish to help. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 19:23 ` Eric S. Raymond 2014-01-31 19:55 ` Juanma Barranquero 2014-01-31 20:30 ` Eli Zaretskii @ 2014-01-31 21:20 ` Sean Sieger 2014-01-31 21:22 ` Sean Sieger 2014-02-01 9:38 ` David Kastrup 4 siblings, 0 replies; 38+ messages in thread From: Sean Sieger @ 2014-01-31 21:20 UTC (permalink / raw) To: emacs-devel After enough pissy, semi-autistic territorial grunting I just start tuning all of it out. No, no. The only pissing on any ground is *your* pissing on the edges of ground you seem only to be guessing at as to the ground's actual existence. And, you have only ever attenuated your attention from the very beginning of your hegemonic effort. Eric. Hegemony works best that way. Or, you can leave me to do all the work alone while flaming from the sidelines. If you choose that, don't blame anyone but yourselves if you think (wrongly) that you've had no influence on the result. Your heroism is blinding. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 19:23 ` Eric S. Raymond ` (2 preceding siblings ...) 2014-01-31 21:20 ` Sean Sieger @ 2014-01-31 21:22 ` Sean Sieger 2014-02-01 9:38 ` David Kastrup 4 siblings, 0 replies; 38+ messages in thread From: Sean Sieger @ 2014-01-31 21:22 UTC (permalink / raw) To: emacs-devel No, no. The only pissing on any ground is *your* pissing on the edges of ground you seem only to be guessing at as to the ground's actual existence. And, you have only ever attenuated your attention from the very beginning of your hegemonic effort. Eric. Hegemony works best that way. Or, you can leave me to do all the work alone while flaming from the sidelines. If you choose that, don't blame anyone but yourselves if you think (wrongly) that you've had no influence on the result. Your heroism is blinding. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 19:23 ` Eric S. Raymond ` (3 preceding siblings ...) 2014-01-31 21:22 ` Sean Sieger @ 2014-02-01 9:38 ` David Kastrup 4 siblings, 0 replies; 38+ messages in thread From: David Kastrup @ 2014-02-01 9:38 UTC (permalink / raw) To: emacs-devel "Eric S. Raymond" <esr@thyrsus.com> writes: > Juanma Barranquero <lekktu@gmail.com>: >> Well, do you at least agree with him when he says >> >> > I'm ignored already. You never accepted any argument of mine through >> > that long and tiresome "discussion". You are always right and all >> > those who disagree with you are always wrong. >> >> and >> >> > I never had any influence over that, because you refuse to listen >> > to any dissenting arguments, and prefer to stubbornly do what you >> > decided was right ahead of any discussion. > > Sigh. I wasn't going to go there, but....in fact I have already done > several work items raised specifically by Eli. That's not my impression. My impression is that you repeatedly pronounce having cleared a self-set bar and when people including Eli point out where you didn't, you make them accountable for setting the bar. Unless your plan involved bullshitting everybody including yourself about the quality of the achieved solution, there is no point in shouting down those who point out where you don't meet your goals. If the ultimate transition is to involve history rewriting involving a change of the existing Git commit ids, and that's the setup you are aiming for partly in order to get a nice showcase for your repo surgeon, then any remaining deficiency is going to be permanent. > I'm a very reasonable person about meeting requirements like that > which are raised in a genuine attempt to improve the quality of the > result. It's for sure no one else is going to do them for you. You'll find that a lot of people have done a lot more work on Emacs than you did, so it is disingenuous to suggest that there is no alternative to letting you have your way. There actually has been a working Git mirror for quite a few years that was set up (and restarted from scratch several times in its infancy) and used without your input. So there clearly _are_ people who have experience in that area, and it's also obvious from the exchanges that there are people who have more knowledge about the kind of labels and references that are in use than you were able to imagine. Locking out their feedback might speed up the time until you are able to declare having finished your task. But it does not help with you being on top of it. > Being reasonable does not, however, mean I will put up with > obstreperous bullshit. What I just quoted, from Juanma and Eli both, > was obstreperous bullshit. That, I respond to by decreasing my > willingness to pay attention to the bullshitter. > > So let me spell it out: Juanma, if you think you are not being > listened to, you have only your own bad attitude to blame for that. > Same goes for you, Eli. After enough pissy, semi-autistic territorial > grunting I just start tuning all of it out. There are several perfectly viable solutions that get along without rewriting the commit history of the existing mirror, by collecting the respective information in plain files and/or Git labels and/or Git notes. Since they work without rewriting, they can be improved and/or fixed over the course of time. Consequently, they don't require the kind of "everything has to be perfect at first try" mind frame that your preferred solution is built around and that you are sabotaging confidence in yourself by locking out feedback. Voting for an "everything has to be perfect at first try" solution requires a trust in the solution that is hard to achieve when you turn it into a one-man show in the face of those who are actual permanent and active contributors to the project. > Conversely, you can earn my attention and increased willingness to do > what you want by putting effort into helping with the work. "to do what you want"? I don't think that's an accurate characterization. Eli does not want to migrate to Git. He is not trying to make you "do what he wants" when he points out where your claims fall flat. He is helping you doing what _you_ want if he raises his objections in a timely and detailed manner where you are able to address them. The nature of a history rewrite does not make it feasible to address them once the conversion is done, and you have made abundantly clear anyway that you only have a limited time window to bother with the conversion and followup. If the quality of the conversion will be such that one will have to revert to auxiliary tools and files created after the conversion to resolve a sizable number of repository-based questions, then it might be easier to just continue reusing the existing mirror together with the auxiliary tools and files one will need anyway. So if you want Emacs to be a showcase for your toolset and skills, you better figure in its existing community in your plans to make a convincing pitch. -- David Kastrup ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 17:56 ` Juanma Barranquero 2014-01-31 19:23 ` Eric S. Raymond @ 2014-01-31 19:31 ` Karl Fogel 2014-01-31 20:18 ` Eli Zaretskii 2014-02-01 11:04 ` Richard Stallman 1 sibling, 2 replies; 38+ messages in thread From: Karl Fogel @ 2014-01-31 19:31 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Eric Raymond, Eli Zaretskii, Emacs developers Juanma Barranquero <lekktu@gmail.com> writes: >On Fri, Jan 31, 2014 at 6:31 PM, Karl Fogel <kfogel@red-bean.com> wrote: > >> I don't agree with Eli's comments in a later mail about how he wasn't >> sure we should entrust this job to ESR. It's a complex, time-consuming, >> and apparently thankless task; IMHO ESR is doing a good job considering >> all the inputs involved (both human and machine). > >Well, do you at least agree with him when he says > >> I'm ignored already. You never accepted any argument of mine through >> that long and tiresome "discussion". You are always right and all >> those who disagree with you are always wrong. > >and > >> I never had any influence over that, because you refuse to listen >> to any dissenting arguments, and prefer to stubbornly do what you >> decided was right ahead of any discussion. > >? My impression -- I've followed the discussions, but have not read every single message or subthread -- is that the above is an exaggeration. >Because that's also my feeling about every single switching-to-git >discussion we've had so far. The only thing Eric has backtracked about >is the imminence of switching, and that because Stefan specifically >said that it wouldn't happen during the freeze. The most important fact about all our prior switching-to-git discussions was that always RMS vetoed the idea, explicitly saying that the number of developers who wanted to switch was not relevant to the decision. He even continued saying this after it was obvious that Bazaar was not in any meaningful sense a GNU project. Given that history, I find it ironic that ESR is now being accused of not listening enough :-). In another followup, ESR wrote: >I hear the argument about forensics, but the Bazaar revision numbers >are no more helpful for that than the action stamps. If anything, >spelunking is an argument for appending those numbers to the change >comment of each revision - leaving them in as references would a >bass-ackwards approach to the problem. > >But there's a better way. We're going to have a complete >revision-to-action-stamp map as part of the record. It would be >pretty easy to write Emacs code that uses that map to find revisions >by Bazaar reference number. That's the right solution, IMO. Okay. I'm not able to pay as close attention to the problem as others here are, but if you feel you've got a plan that handles the forensic case well enough, that's fine by me. There are a million ways to convert a bzr history to git. We just need to pick one of those ways that will work for Emacs development. (insert the usual comment about diminishing returns, lather, rinse, repeat?) Best, -Karl ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 19:31 ` Karl Fogel @ 2014-01-31 20:18 ` Eli Zaretskii 2014-02-01 11:04 ` Richard Stallman 1 sibling, 0 replies; 38+ messages in thread From: Eli Zaretskii @ 2014-01-31 20:18 UTC (permalink / raw) To: Karl Fogel; +Cc: esr, lekktu, emacs-devel > From: Karl Fogel <kfogel@red-bean.com> > Cc: Eli Zaretskii <eliz@gnu.org>, Eric Raymond <esr@thyrsus.com>, Emacs developers <emacs-devel@gnu.org> > Date: Fri, 31 Jan 2014 13:31:37 -0600 > > The most important fact about all our prior switching-to-git discussions > was that always RMS vetoed the idea, explicitly saying that the number > of developers who wanted to switch was not relevant to the decision. He > even continued saying this after it was obvious that Bazaar was not in > any meaningful sense a GNU project. > > Given that history, I find it ironic that ESR is now being accused of > not listening enough :-). So you are saying that no one can ever be accused of not listening enough, unless we also accuse RMS? Is that what you are saying? ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 19:31 ` Karl Fogel 2014-01-31 20:18 ` Eli Zaretskii @ 2014-02-01 11:04 ` Richard Stallman 1 sibling, 0 replies; 38+ messages in thread From: Richard Stallman @ 2014-02-01 11:04 UTC (permalink / raw) To: Karl Fogel; +Cc: esr, lekktu, eliz, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] He even continued saying this after it was obvious that Bazaar was not in any meaningful sense a GNU project. There is only one GNU Project. Bazaar was and is a GNU package. It is a GNU package because I dubbed it one -- like every other GNU package. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 17:31 ` Karl Fogel 2014-01-31 17:56 ` Juanma Barranquero @ 2014-01-31 18:16 ` Eric S. Raymond 2014-01-31 19:44 ` Paul Eggert 2014-01-31 21:03 ` Stefan Monnier 1 sibling, 2 replies; 38+ messages in thread From: Eric S. Raymond @ 2014-01-31 18:16 UTC (permalink / raw) To: Karl Fogel; +Cc: Eli Zaretskii, emacs-devel Karl Fogel <kfogel@red-bean.com>: > I agree with Eli's point above, FWIW (and not just because he happened > to use one of my (sadly rarer than I would like) commits as an example). This could be done with a relatively simple series of changes to the lift file. (Everybody should be paying attention to the lift script drafts! This is my way of exposing the conversion process to review, as well as making it repeatable so that the cost of correcting errors is low.) There's a practical problem with it, however. Where a Bazaar revision number is typically 5 or 6 characters an action stamp is a minimum of 28 and typically about 40. Fortunately we can often get some of that back by removing an unneeded "revision" or "revno:" prefix. Still, replacing with the action stamp already makes the patched references unpleasantly long in some cases. Adding the action stamp *and* leaving the Bazaar revision in place would produce results that in many cases are significantly harder to read. This is the main reason I don't want to do it. The whole point of what I'm doing is to *lower* the friction costs of browsing the history, not raise them. I hear the argument about forensics, but the Bazaar revision numbers are no more helpful for that than the action stamps. If anything, spelunking is an argument for appending those numbers to the change comment of each revision - leaving them in as references would a bass-ackwards approach to the problem. But there's a better way. We're going to have a complete revision-to-action-stamp map as part of the record. It would be pretty easy to write Emacs code that uses that map to find revisions by Bazaar reference number. That's the right solution, IMO. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 18:16 ` Eric S. Raymond @ 2014-01-31 19:44 ` Paul Eggert 2014-01-31 21:07 ` Eric S. Raymond 2014-01-31 21:03 ` Stefan Monnier 1 sibling, 1 reply; 38+ messages in thread From: Paul Eggert @ 2014-01-31 19:44 UTC (permalink / raw) To: esr; +Cc: emacs-devel Eric S. Raymond wrote: > I hear the argument about forensics, but the Bazaar revision numbers > are no more helpful for that than the action stamps. As someone who regularly spelunks back decades, I'd prefer keeping these stamps as small as possible. Even "2003-07-05T12:41:24!Roland.Winkler@physik.uni-erlangen.de" will cause hassles, and I especially wouldn't want to read and digest monsters along the lines of what someone else proposed, e.g., "1985-04-18T00:49:29!jimb@redhat.com (bzr 1) (CVS 4.35.2.1) (RCS 1.71) (emacs-backup ~107~)". It doesn't scale for a revision string to contain all the names that the revision has ever had, for all the version-control systems we've ever used. It may be that leaving commentary alone is the simplest and best way to keep it short and readable, with a map elsewhere that converts old notation. That being said, I'm willing to give your approach a try. As long as the complete history is available somewhere and is documented, and it's not too much work to use it, it should be OK. PS. In that 1985 example, the email address jimb@redhat.com is ahistorical, as Red Hat didn't exist in 1985. That info is taken straight from the current bzr repository. Most likely the repository was made ahistorical during an earlier conversion, unfortunately. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 19:44 ` Paul Eggert @ 2014-01-31 21:07 ` Eric S. Raymond 2014-02-01 0:05 ` Paul Eggert 0 siblings, 1 reply; 38+ messages in thread From: Eric S. Raymond @ 2014-01-31 21:07 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel Paul Eggert <eggert@cs.ucla.edu>: > Eric S. Raymond wrote: > >I hear the argument about forensics, but the Bazaar revision numbers > >are no more helpful for that than the action stamps. > > As someone who regularly spelunks back decades, I'd prefer keeping > these stamps as small as possible. Even > "2003-07-05T12:41:24!Roland.Winkler@physik.uni-erlangen.de" will > cause hassles, and I especially wouldn't want to read and digest > monsters along the lines of what someone else proposed, e.g., > "1985-04-18T00:49:29!jimb@redhat.com (bzr 1) (CVS 4.35.2.1) (RCS > 1.71) (emacs-backup ~107~)". It doesn't scale for a revision string > to contain all the names that the revision has ever had, for all the > version-control systems we've ever used. Yeah, exactly. That's the telling argument for a single VCS-independent action stamp, right there. And props to you for taking the (correctly) long view of the matter! I'm not real happy about the action stamps being so long as it is. Unfortunately, they're the shortest thing I've managed to come up with that has the required properties of being unique and self-describing. > PS. In that 1985 example, the email address jimb@redhat.com is > ahistorical, as Red Hat didn't exist in 1985. That info is taken > straight from the current bzr repository. Most likely the > repository was made ahistorical during an earlier conversion, > unfortunately. Yes, and that sort of ahistoricity was unavoidable for the simple reason that DVCSes need email addresses as Internet-global credentials. The act of mapping CVS usernames to these therefore almost necessarily introduces anachronisms. Repository translation is *difficult*. At least, doing a non-half-assed job of it is. The tradeoffs between usability and historicity don't have easy or pat answers. It's especially difficult for a project as steeped in history - nay, positively encrusted with it - as Emacs. This is already the hairiest conversion I've ever done, measured by complexity of the lift file, and it's going to get much worse before it's done. I don't expect to ever see a messier one. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 21:07 ` Eric S. Raymond @ 2014-02-01 0:05 ` Paul Eggert 2014-02-01 0:25 ` Juanma Barranquero ` (3 more replies) 0 siblings, 4 replies; 38+ messages in thread From: Paul Eggert @ 2014-02-01 0:05 UTC (permalink / raw) To: esr; +Cc: emacs-devel Eric S. Raymond wrote: > I'm not real happy about the action stamps being so long as it is. How about a POSIX timestamp rather than an ISO 8601 string? "1391204651!larsi@gnus.org", for example, instead of "2014-01-31T21:44:11!larsi@gnus.org". Although it's just 9 characters difference, the savings add up when you're trying to read a screenful of these things. The ISO 8601 string is not that readable, nor does it match the localtime clock of committer, so it's a bit of a magic cookie anyway. As I understand it the first glimmer of Emacs in RMS's eye was circa 1972, so even if we magically resurrected his original code the timestamps would never need to be negative. We could say that time-since-1970 is "Emacs time". ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-02-01 0:05 ` Paul Eggert @ 2014-02-01 0:25 ` Juanma Barranquero 2014-02-01 4:19 ` Eric S. Raymond ` (2 subsequent siblings) 3 siblings, 0 replies; 38+ messages in thread From: Juanma Barranquero @ 2014-02-01 0:25 UTC (permalink / raw) To: Paul Eggert; +Cc: Emacs developers On Sat, Feb 1, 2014 at 1:05 AM, Paul Eggert <eggert@cs.ucla.edu> wrote: > The ISO 8601 string is not that readable I find it perfectly readable. >, nor does it match the localtime > clock of committer For some of us is close enough, and anyway it is a fixed offset (modulo DST) from your local time, so it is not opaque or a magic cookie at all. J ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-02-01 0:05 ` Paul Eggert 2014-02-01 0:25 ` Juanma Barranquero @ 2014-02-01 4:19 ` Eric S. Raymond 2014-02-01 8:40 ` Eli Zaretskii 2014-02-02 1:03 ` Stefan Monnier 3 siblings, 0 replies; 38+ messages in thread From: Eric S. Raymond @ 2014-02-01 4:19 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel Paul Eggert <eggert@cs.ucla.edu>: > Eric S. Raymond wrote: > >I'm not real happy about the action stamps being so long as it is. > > How about a POSIX timestamp rather than an ISO 8601 string? > "1391204651!larsi@gnus.org", for example, instead of > "2014-01-31T21:44:11!larsi@gnus.org". Although it's just 9 > characters difference, the savings add up when you're trying to read > a screenful of these things. Clever hack! I really, really liked this idea - for about thirty seconds. Then I remembered, dammit, that I have run into a fair amount of confusion over whether that kind of Unix time is based on a UTC or local epoch. That's why the Z in RFC3339 date format is functional; it pins the stamp to Zulu time. Yes, I know POSIX time is supposed to be seconds UTC (sort of, modulo leap seconds). People get confused anyway - in fact I remember a Linux distribution that actually gave you an installation choice about whether to keep your integer timestamps in local or in UTC a la POSIX. I boggled. If we leave this ambiguous in the representation, someone in the future will curse us. And not without reason. Because even if they know the right UTC-based interpretation of Unix time, they have no way to be sure everyone who touched the data *before* them did. (Wearing my GPSD maintainer hat I have to deal with crap like this a lot.) More generally, we'd lose the self-describing property. It's hard to look at an RFC3339 timestamp and not know what it is. Not so much with an integer literal. So yes, a clever hack. But, alas. Not, I fear, a good one. If we really had to deal with screenfulls of these things the tradeoff might potentially be different. That actually happened in the change comments of the NUT project. Not here, though. The worst case I've seen in the Emacs history is two of them per line, one pair per commit message or ChangeLog entry. > As I understand it the first glimmer of Emacs in RMS's eye was circa > 1972, so even if we magically resurrected his original code the > timestamps would never need to be negative. We could say that > time-since-1970 is "Emacs time". Ha. You know what popped into my head when I read that last? "1970 is as old as the world." Text Editors in The Lord of the Rings http://crookedtimber.org/2011/07/30/text-editors-in-the-lord-of-the-rings/ Emacs: Fangorn Vast, ancient, gnarled and mostly impenetrable, tended by a small band of shepherds old as the world itself, under the command of their leader, Neckbeard. They possess unbelievable strength, are infuriatingly slow, and their land is entirely devoid of women. It takes forever to say anything in their strange, rumbling language. When I read that, I do not mind telling you that I felt my age. :-) I've been thinking about that satire a lot lately. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-02-01 0:05 ` Paul Eggert 2014-02-01 0:25 ` Juanma Barranquero 2014-02-01 4:19 ` Eric S. Raymond @ 2014-02-01 8:40 ` Eli Zaretskii 2014-02-02 1:03 ` Stefan Monnier 3 siblings, 0 replies; 38+ messages in thread From: Eli Zaretskii @ 2014-02-01 8:40 UTC (permalink / raw) To: Paul Eggert; +Cc: esr, emacs-devel > Date: Fri, 31 Jan 2014 16:05:49 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > Cc: emacs-devel@gnu.org > > How about a POSIX timestamp rather than an ISO 8601 string? > "1391204651!larsi@gnus.org", for example, instead of > "2014-01-31T21:44:11!larsi@gnus.org". Please don't. These strings are for human consumption. "2014-01-31T21:44:11" is easily parsed by humans, while "1391204651" needs some program to convert it to human-readable time stamp. If you look at this text outside of Emacs, the conversion is not easy, and even inside Emacs it needs to type a command, which is a nuisance. > The ISO 8601 string is not that readable, nor does it match the > localtime clock of committer, so it's a bit of a magic cookie anyway. It's a magic cookie which is easily interpreted by simply reading it. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-02-01 0:05 ` Paul Eggert ` (2 preceding siblings ...) 2014-02-01 8:40 ` Eli Zaretskii @ 2014-02-02 1:03 ` Stefan Monnier 3 siblings, 0 replies; 38+ messages in thread From: Stefan Monnier @ 2014-02-02 1:03 UTC (permalink / raw) To: Paul Eggert; +Cc: esr, emacs-devel > How about a POSIX timestamp rather than an ISO 8601 string? > "1391204651!larsi@gnus.org", for example, instead of We could also use some kind of huffman encoding, to save yet more characters. Stefan "seriously, let's try to keep those beasts semi-readable, please" ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 18:16 ` Eric S. Raymond 2014-01-31 19:44 ` Paul Eggert @ 2014-01-31 21:03 ` Stefan Monnier 2014-01-31 21:51 ` Eric S. Raymond 1 sibling, 1 reply; 38+ messages in thread From: Stefan Monnier @ 2014-01-31 21:03 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Karl Fogel, Eli Zaretskii, emacs-devel > I hear the argument about forensics, but the Bazaar revision numbers > are no more helpful for that than the action stamps. If anything, > spelunking is an argument for appending those numbers to the change > comment of each revision - leaving them in as references would a > bass-ackwards approach to the problem. Moving the "equiv to bzr r123456" to the commit message of that corresponding Git commit sounds like an good compromise. Of course, we don't need it for every commit, but for all those commits that have a corresponding "action stamp". > But there's a better way. We're going to have a complete > revision-to-action-stamp map as part of the record. It would be > pretty easy to write Emacs code that uses that map to find revisions > by Bazaar reference number. That's the right solution, IMO. But where would this map be stored? Keeping it directly in the commit log sounds like a better approach. Stefan ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 21:03 ` Stefan Monnier @ 2014-01-31 21:51 ` Eric S. Raymond 2014-01-31 23:15 ` Jan D. 2014-01-31 23:16 ` Stefan Monnier 0 siblings, 2 replies; 38+ messages in thread From: Eric S. Raymond @ 2014-01-31 21:51 UTC (permalink / raw) To: Stefan Monnier; +Cc: Karl Fogel, Eli Zaretskii, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca>: > > I hear the argument about forensics, but the Bazaar revision numbers > > are no more helpful for that than the action stamps. If anything, > > spelunking is an argument for appending those numbers to the change > > comment of each revision - leaving them in as references would a > > bass-ackwards approach to the problem. > > Moving the "equiv to bzr r123456" to the commit message of that > corresponding Git commit sounds like an good compromise. Of course, we > don't need it for every commit, but for all those commits that have > a corresponding "action stamp". Technically, I could do this. It would take a minor extension of reposurgeon, but that is in itself OK because I'm going to have to build that same primitive to do the thing Eli Zaretskii wanted (fixes-bugs headers folded into the commit comments). Let me explain this; it will give some insight into my working methods. The primitive I plan to add to reposurgeon will be called "append" or some verb like that. It will take two arguments; one commit identifier, one string. The effect will be to append the specified line to the specifed commit comment. Then, I would extract a list of revisions to be marked from my master FOSSILS file and compile it into a sequence of append commands. So, for ecample, this association: 100984 -> 2010-08-05T23:34:12Z!dann@ics.uci.edu would compile to this append command: <2010-08-05T23:34:12Z!dann@ics.uci.edu> append "\nBazaar revision 100984" For Eli's feature, I would build a map from revisions to fixes-bug numbers by mechanically analyzing the output of bzr log, then generating append commands like this: <2010-08-05T23:34:12Z!dann@ics.uci.edu> append "\nFixes bug 2317" All these append commands would be appended to the lift script to be applied on conversion day. These things can be done. The question is whether they *should* be done. Because with each benefit there also comes a cost. There is a real cost to burdening the commit comments with an ever-increasing load of fossil data. As Paul Eggert pointed out in connection with references, this will scale badly over time. Additionally, while none of these processing steps (or many others like them) are difficult in principle, they accumulate to a huge load of work for me. Accordingly, I want to hear a use-case analysis. That is, rather than relatively vague hand-waving about forensics I want somebody with a stake in the process *other than me* to lay out a set of user stories about what kinds of navigation and lookup we want to support, so that potential data representations (map file, in-commit comments, etc.) can be checked against those stories. Here's an example of a user story: Someone is reading the emacs-devel archives and reads mail containing a reference to an Emacs change by Bazaar revision. How does he get to the corresponding git revision? What other user stories are there? What do they tell us about acceptable gradients in lookup costs? What does that tell us about good metadata representations? I think I know what many of the conclusions will look like. I've been around this track before! But others might educate me, and will certainly educate some of the rest of you. > > But there's a better way. We're going to have a complete > > revision-to-action-stamp map as part of the record. It would be > > pretty easy to write Emacs code that uses that map to find revisions > > by Bazaar reference number. That's the right solution, IMO. > > But where would this map be stored? /etc, same as any other static data used by a mode. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 21:51 ` Eric S. Raymond @ 2014-01-31 23:15 ` Jan D. 2014-02-01 4:22 ` Eric S. Raymond 2014-01-31 23:16 ` Stefan Monnier 1 sibling, 1 reply; 38+ messages in thread From: Jan D. @ 2014-01-31 23:15 UTC (permalink / raw) To: esr@thyrsus.com Cc: Karl Fogel, Eli Zaretskii, Stefan Monnier, emacs-devel@gnu.org Hi. > 31 jan 2014 kl. 22:51 skrev "Eric S. Raymond" <esr@thyrsus.com>: > > Here's an example of a user story: Someone is reading the emacs-devel > archives and reads mail containing a reference to an Emacs change by > Bazaar revision. How does he get to the corresponding git revision? > > What other user stories are there? Somebody looking up a bug report containing a reference. This is not uncommon. Jan D. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 23:15 ` Jan D. @ 2014-02-01 4:22 ` Eric S. Raymond 0 siblings, 0 replies; 38+ messages in thread From: Eric S. Raymond @ 2014-02-01 4:22 UTC (permalink / raw) To: Jan D.; +Cc: Karl Fogel, Eli Zaretskii, Stefan Monnier, emacs-devel@gnu.org Jan D. <jan.h.d@swipnet.se>: > > What other user stories are there? > > Somebody looking up a bug report containing a reference. > This is not uncommon. Yeah, that's a good one. I'll start keeping a list. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 21:51 ` Eric S. Raymond 2014-01-31 23:15 ` Jan D. @ 2014-01-31 23:16 ` Stefan Monnier 2014-02-01 4:26 ` Eric S. Raymond 2014-02-01 11:04 ` Eli Zaretskii 1 sibling, 2 replies; 38+ messages in thread From: Stefan Monnier @ 2014-01-31 23:16 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Karl Fogel, Eli Zaretskii, emacs-devel > <2010-08-05T23:34:12Z!dann@ics.uci.edu> append "\nFixes bug 2317" (with-nitpick-mode Should be "\nFixes bug#2317") > There is a real cost to burdening the commit comments with an > ever-increasing load of fossil data. As Paul Eggert pointed out in > connection with references, this will scale badly over time. For the "Fixes bug#NNN", this cost is not does not accumulate: it was there already and we just translate it in another form. For the references, it is true that they can accumulate. But we shouldn't say "Bazaar revision NNNN; CVS revision 1.MM; RCS revision 1.PP". Instead we should only keep the original reference text (in the above case it would be "RCS 1.PP"), so they don't accumulate either. > Additionally, while none of these processing steps (or many others like > them) are difficult in principle, they accumulate to a huge load > of work for me. To reduce the load, you can just skip the "conversion to action stamps". I think it's more important to preserve their correctness (i.e. not touch them) than to make them easy to use. > Accordingly, I want to hear a use-case analysis. That is, rather than > relatively vague hand-waving about forensics I want somebody with a > stake in the process *other than me* to lay out a set of user stories > about what kinds of navigation and lookup we want to support, so that > potential data representations (map file, in-commit comments, etc.) > can be checked against those stories. I know I won't be using any external data file because I need such a thing rarely enough that I won't remember where the file is or which command to use for that. Also they're rare enough that it's OK if it takes a while to figure out what it's referring to. > Here's an example of a user story: Someone is reading the emacs-devel > archives and reads mail containing a reference to an Emacs change by > Bazaar revision. How does he get to the corresponding git revision? He doesn't and moves on. Or he goes back to the old Bzr repository to figure it out. For fixes it's very different. The way it works is: vc-annotate tells me the code was changed in commit NNNN and that commit says it's linked to bug#MMMM so I go check bug#MMMM to try and understand why the code is the way it is. This is a fairly common occurrence, and it's common to use the bug#NNNN reference as an "excuse" to keep the commit log shorter, so it's important to preserve this info. Stefan ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 23:16 ` Stefan Monnier @ 2014-02-01 4:26 ` Eric S. Raymond 2014-02-01 11:04 ` Eli Zaretskii 1 sibling, 0 replies; 38+ messages in thread From: Eric S. Raymond @ 2014-02-01 4:26 UTC (permalink / raw) To: Stefan Monnier; +Cc: Karl Fogel, Eli Zaretskii, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca>: > To reduce the load, you can just skip the "conversion to action stamps". I've already paid the time and complexity cost for that. There's not really a savings there. > For fixes it's very different. The way it works is: vc-annotate tells > me the code was changed in commit NNNN and that commit says it's linked > to bug#MMMM so I go check bug#MMMM to try and understand why the code is > the way it is. This is a fairly common occurrence, and it's common to > use the bug#NNNN reference as an "excuse" to keep the commit log > shorter, so it's important to preserve this info. I agree. This goes on the list of use cases that needs to be supported -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-01-31 23:16 ` Stefan Monnier 2014-02-01 4:26 ` Eric S. Raymond @ 2014-02-01 11:04 ` Eli Zaretskii 2014-02-02 0:58 ` Stefan Monnier 1 sibling, 1 reply; 38+ messages in thread From: Eli Zaretskii @ 2014-02-01 11:04 UTC (permalink / raw) To: Stefan Monnier; +Cc: esr, kfogel, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Fri, 31 Jan 2014 18:16:25 -0500 > Cc: Karl Fogel <kfogel@red-bean.com>, Eli Zaretskii <eliz@gnu.org>, > emacs-devel@gnu.org > > I know I won't be using any external data file because I need such > a thing rarely enough that I won't remember where the file is or which > command to use for that. > > Also they're rare enough that it's OK if it takes a while to figure out > what it's referring to. > > > Here's an example of a user story: Someone is reading the emacs-devel > > archives and reads mail containing a reference to an Emacs change by > > Bazaar revision. How does he get to the corresponding git revision? > > He doesn't and moves on. Or he goes back to the old Bzr repository to > figure it out. We could have a VC command that consults an external file with the mapping. We could even display the results of such mapping in a tooltip or in a display property. Then the need to remember will disappear. I do agree (and thought so from the get-go) that conversion of old revision references to time stamps is a lot of effort for little gain. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-02-01 11:04 ` Eli Zaretskii @ 2014-02-02 0:58 ` Stefan Monnier 2014-02-02 10:24 ` Eric S. Raymond 0 siblings, 1 reply; 38+ messages in thread From: Stefan Monnier @ 2014-02-02 0:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, kfogel, emacs-devel >> He doesn't and moves on. Or he goes back to the old Bzr repository to >> figure it out. > We could have a VC command that consults an external file with the > mapping. We could even display the results of such mapping in a > tooltip or in a display property. Then the need to remember will > disappear. And then arrange for that extra code to be triggered only for the case we're looking at an Emacs revision? Sounds difficult/impossible. We'll need some explicit user action. "over-engineering" is the word that comes to mind. Stefan ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Repo cpnversion progress report 2014-02-02 0:58 ` Stefan Monnier @ 2014-02-02 10:24 ` Eric S. Raymond 0 siblings, 0 replies; 38+ messages in thread From: Eric S. Raymond @ 2014-02-02 10:24 UTC (permalink / raw) To: Stefan Monnier; +Cc: kfogel, Eli Zaretskii, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca>: > >> He doesn't and moves on. Or he goes back to the old Bzr repository to > >> figure it out. > > We could have a VC command that consults an external file with the > > mapping. We could even display the results of such mapping in a > > tooltip or in a display property. Then the need to remember will > > disappear. > > And then arrange for that extra code to be triggered only for the case > we're looking at an Emacs revision? Sounds difficult/impossible. > We'll need some explicit user action. "over-engineering" is the word > that comes to mind. 100% with Stefan on this. IMO it's not so common a use case that heroic measures are required. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2014-02-02 10:24 UTC | newest] Thread overview: 38+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-01-30 19:55 Repo cpnversion progress report Eric S. Raymond 2014-01-30 20:11 ` Andreas Schwab 2014-01-30 20:27 ` Eric S. Raymond 2014-01-30 22:04 ` Andreas Schwab 2014-01-30 21:23 ` Eli Zaretskii 2014-01-30 21:42 ` Eric S. Raymond 2014-01-31 7:50 ` Eli Zaretskii 2014-01-31 15:25 ` Eric S. Raymond 2014-01-31 15:57 ` David Kastrup 2014-01-31 16:15 ` Eli Zaretskii 2014-01-31 17:31 ` Karl Fogel 2014-01-31 17:56 ` Juanma Barranquero 2014-01-31 19:23 ` Eric S. Raymond 2014-01-31 19:55 ` Juanma Barranquero 2014-01-31 20:30 ` Eli Zaretskii 2014-01-31 21:20 ` Sean Sieger 2014-01-31 21:22 ` Sean Sieger 2014-02-01 9:38 ` David Kastrup 2014-01-31 19:31 ` Karl Fogel 2014-01-31 20:18 ` Eli Zaretskii 2014-02-01 11:04 ` Richard Stallman 2014-01-31 18:16 ` Eric S. Raymond 2014-01-31 19:44 ` Paul Eggert 2014-01-31 21:07 ` Eric S. Raymond 2014-02-01 0:05 ` Paul Eggert 2014-02-01 0:25 ` Juanma Barranquero 2014-02-01 4:19 ` Eric S. Raymond 2014-02-01 8:40 ` Eli Zaretskii 2014-02-02 1:03 ` Stefan Monnier 2014-01-31 21:03 ` Stefan Monnier 2014-01-31 21:51 ` Eric S. Raymond 2014-01-31 23:15 ` Jan D. 2014-02-01 4:22 ` Eric S. Raymond 2014-01-31 23:16 ` Stefan Monnier 2014-02-01 4:26 ` Eric S. Raymond 2014-02-01 11:04 ` Eli Zaretskii 2014-02-02 0:58 ` Stefan Monnier 2014-02-02 10:24 ` Eric S. Raymond
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.