{"thread":{"id":"4812","subject":"[RFC+PATCH 1/1] Move SCM interoperability tools into scm/","startedAt":"2006-07-09T06:17:06Z","lastAt":"2006-07-10T09:45:25Z","messageCount":11,"participants":["Ryan Anderson","Johannes Schindelin","Martin Langhoff","Petr Baudis","Timo Hirvonen","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"23450","messageId":"11524258261798-git-send-email-ryan@michonline.com","threadId":"4812","inReplyTo":null,"subject":"[RFC+PATCH 1/1] Move SCM interoperability tools into scm/","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-07-09T06:17:06Z","receivedAt":"2006-07-09T06:17:06Z","isPatch":true,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"Signed-off-by: Ryan Anderson \n---\n\nThis is the first in a series to categorize the source tree a little bit more\nthan it is currently.\n\nI figured I'd start with something innocuous, like the SCM interoperability\ntools.\n\nOne thing I don't really like is that I had to duplicate the Perl build rule\nin the subdirectory Makefile, effectively, to restructure it and leave the\nbuilt files in the root. If we can deprecate \"run from the source tree\",\nthis can go away. (That requires fixing up a lot of tests, but it's\nstraightforward, at least.)\n\nSo, flame away!\n\n\n Makefile | 10 ++++++----\n scm/Makefile | 20 ++++++++++++++++++++\n git-archimport.perl => scm/git-archimport.perl | 0 \n .../git-cvsexportcommit.perl | 0 \n git-cvsimport.perl => scm/git-cvsimport.perl | 0 \n git-cvsserver.perl => scm/git-cvsserver.perl | 0 \n git-p4import.py => scm/git-p4import.py | 0 \n git-send-email.perl => scm/git-send-email.perl | 0 \n git-svnimport.perl => scm/git-svnimport.perl | 0 \n 9 files changed, 26 insertions(+), 4 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 202f261..e7f5b48 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -130,11 +130,10 @@ SCRIPT_SH = \\\n \tgit-lost-found.sh git-quiltimport.sh\n \n SCRIPT_PERL = \\\n-\tgit-archimport.perl git-cvsimport.perl git-relink.perl \\\n+\tgit-relink.perl \\\n \tgit-shortlog.perl git-rerere.perl \\\n-\tgit-annotate.perl git-cvsserver.perl \\\n-\tgit-svnimport.perl git-mv.perl git-cvsexportcommit.perl \\\n-\tgit-send-email.perl\n+\tgit-annotate.perl \\\n+\tgit-mv.perl\n \n SCRIPT_PYTHON = \\\n \tgit-merge-recursive.py\n@@ -176,6 +175,9 @@ BUILT_INS = git-log$X git-whatchanged$X \n \tgit-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X \\\n \tgit-fmt-merge-msg$X\n \n+\n+include scm/Makefile\n+\n # what 'all' will build and 'install' will install, in gitexecdir\n ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)\n \ndiff --git a/scm/Makefile b/scm/Makefile\nnew file mode 100644\nindex 0000000..0ce205b\n--- /dev/null\n+++ b/scm/Makefile\n@@ -0,0 +1,20 @@\n+\n+SCM_PERL_BASE = \\\n+\tgit-archimport.perl \\\n+\tgit-cvsimport.perl \\\n+\tgit-cvsexportcommit.perl \\\n+\tgit-cvsserver.perl \\\n+\tgit-svnimport.perl \\\n+\tgit-send-email.perl\n+\n+SCRIPTS+=$(patsubst %.perl,%,$(SCM_PERL_BASE))\n+\n+$(patsubst %.perl,%,$(SCM_PERL_BASE)) : % : scm/%.perl\n+\trm -f $@ $@+\n+\tsed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \\\n+\t -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n+\t $^ >$@+\n+\tchmod +x $@+\n+\tmv $@+ $@\n+\n+\ndiff --git a/git-archimport.perl b/scm/git-archimport.perl\nsimilarity index 100%\nrename from git-archimport.perl\nrename to scm/git-archimport.perl\ndiff --git a/git-cvsexportcommit.perl b/scm/git-cvsexportcommit.perl\nsimilarity index 100%\nrename from git-cvsexportcommit.perl\nrename to scm/git-cvsexportcommit.perl\ndiff --git a/git-cvsimport.perl b/scm/git-cvsimport.perl\nsimilarity index 100%\nrename from git-cvsimport.perl\nrename to scm/git-cvsimport.perl\ndiff --git a/git-cvsserver.perl b/scm/git-cvsserver.perl\nsimilarity index 100%\nrename from git-cvsserver.perl\nrename to scm/git-cvsserver.perl\ndiff --git a/git-p4import.py b/scm/git-p4import.py\nsimilarity index 100%\nrename from git-p4import.py\nrename to scm/git-p4import.py\ndiff --git a/git-send-email.perl b/scm/git-send-email.perl\nsimilarity index 100%\nrename from git-send-email.perl\nrename to scm/git-send-email.perl\ndiff --git a/git-svnimport.perl b/scm/git-svnimport.perl\nsimilarity index 100%\nrename from git-svnimport.perl\nrename to scm/git-svnimport.perl\n-- \n1.4.1.gc473b-dirty\n"},{"id":"23480","messageId":"Pine.LNX.4.63.0607091631000.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4812","inReplyTo":"11524258261798-git-send-email-ryan@michonline.com","subject":"Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-09T14:31:54Z","receivedAt":"2006-07-09T14:31:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 9 Jul 2006, Ryan Anderson wrote:\n\n> If we can deprecate \"run from the source tree\", this can go away. \n\nYou would make yours truly very sad. Besides, for the tests we need the \nfunctionality anyway.\n\nCiao,\nDscho\n"},{"id":"23494","messageId":"46a038f90607091426u5a6ea328h2090a876e51725ce@mail.gmail.com","threadId":"4812","inReplyTo":"11524258261798-git-send-email-ryan@michonline.com","subject":"Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-07-09T21:26:59Z","receivedAt":"2006-07-09T21:26:59Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 7/9/06, Ryan Anderson wrote:\n> This is the first in a series to categorize the source tree a little bit more\n> than it is currently.\n\nGiven that you title it RFC, I guess it hasn't been discussed before.\nI personally don't see much benefit from the move/rename. The tree is\nnot so large, the SCM import/export utilities are a single file each\nand their names are quite clear. Having /contrib is more an issue of\nmarking utilities there as 'new, experimental, unsupported', and the\nassumption is that when something matures it moves out of /contrib.\n\nSo I have to ask... what are the expected benefits of the move?\n\nIn any case, use /interop instead. /scm in the tree of an SCM could be\nanything ;-)\n\n\n\nmartin\n"},{"id":"23497","messageId":"20060709221326.GU29115@pasky.or.cz","threadId":"4812","inReplyTo":"46a038f90607091426u5a6ea328h2090a876e51725ce@mail.gmail.com","subject":"Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-09T22:13:26Z","receivedAt":"2006-07-09T22:13:26Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter\nwhere Martin Langhoff said that...\n> So I have to ask... what are the expected benefits of the move?\n\nI've been meaning to do something like this for some time already; my\nitch have been the builtins. The tree size _is_ getting out of hand and\na little more categorization of the sources would certainly help.\nAlthough I'd take a different approach:\n\n\tlibgit/\n\tbuiltin/\n\tstandalone/\n\tscripts/\n\n> In any case, use /interop instead. /scm in the tree of an SCM could be\n> anything ;-)\n\nI agree on this point.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"23499","messageId":"Pine.LNX.4.63.0607100018380.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4812","inReplyTo":"20060709221326.GU29115@pasky.or.cz","subject":"Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-09T22:21:36Z","receivedAt":"2006-07-09T22:21:36Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 10 Jul 2006, Petr Baudis wrote:\n\n> Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter\n> where Martin Langhoff said that...\n> > So I have to ask... what are the expected benefits of the move?\n> \n> I've been meaning to do something like this for some time already; my\n> itch have been the builtins. The tree size _is_ getting out of hand and\n> a little more categorization of the sources would certainly help.\n\nFunny. I thought the builtin-* prefix, and the *.sh and *.perl extensions \nwere there for the sake of categorization.\n\nAnd I disagree on the \"out of hand\" thing.\n\nCiao,\nDscho\n"},{"id":"23501","messageId":"20060709222308.GA4153@h4x0r5.com","threadId":"4812","inReplyTo":"20060709221326.GU29115@pasky.or.cz","subject":"Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-07-09T22:23:09Z","receivedAt":"2006-07-09T22:23:09Z","isPatch":true,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Mon, Jul 10, 2006 at 12:13:26AM +0200, Petr Baudis wrote:\n> Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter\n> where Martin Langhoff said that...\n> > So I have to ask... what are the expected benefits of the move?\n> \n> I've been meaning to do something like this for some time already; my\n> itch have been the builtins. The tree size _is_ getting out of hand and\n> a little more categorization of the sources would certainly help.\n\nThat's what I was thinking, as well, basically. I started with the \"scm\ninterop\" tools because they should be the least controversial to move\naround.\n\n> Although I'd take a different approach:\n> \n> \tlibgit/\n> \tbuiltin/\n> \tstandalone/\n> \tscripts/\n> \n> > In any case, use /interop instead. /scm in the tree of an SCM could be\n> > anything ;-)\n> \n> I agree on this point.\n\nVery good point.\n\nSo these seem obvious to me:\n\tlibgit/ (maybe just lib/?)\n\tbuiltin/\n\tinterop/\n\nI'm less sure of the rest, but I'll poke at doing the above for the\nmoment, and worry about the rest later.\n\nComments on a way to make the Makefile less repetitive would be\nappreciated, though.\n\n\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"},{"id":"23503","messageId":"20060710013405.54fbe6bb.tihirvon@gmail.com","threadId":"4812","inReplyTo":"20060709221326.GU29115@pasky.or.cz","subject":"Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-07-09T22:34:05Z","receivedAt":"2006-07-09T22:34:05Z","isPatch":true,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"Petr Baudis wrote:\n\n> I've been meaning to do something like this for some time already; my\n> itch have been the builtins. The tree size _is_ getting out of hand and\n> a little more categorization of the sources would certainly help.\n> Although I'd take a different approach:\n> \n> \tlibgit/\n> \tbuiltin/\n> \tstandalone/\n> \tscripts/\n\nPlease don't. One directory is much easier to work with. At least\ndon't split the Makefile. Also moving files makes \"git log \"\nstop at the rename.\n\n-- \nhttp://onion.dynserv.net/~timo/\n"},{"id":"23505","messageId":"44B19D42.6030701@michonline.com","threadId":"4812","inReplyTo":"20060710013405.54fbe6bb.tihirvon@gmail.com","subject":"Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-07-10T00:20:18Z","receivedAt":"2006-07-10T00:20:18Z","isPatch":true,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"Timo Hirvonen wrote:\n> Petr Baudis wrote:\n>\n> \n>> I've been meaning to do something like this for some time already; my\n>> itch have been the builtins. The tree size _is_ getting out of hand and\n>> a little more categorization of the sources would certainly help.\n>> Although I'd take a different approach:\n>>\n>> \tlibgit/\n>> \tbuiltin/\n>> \tstandalone/\n>> \tscripts/\n>> \n>\n> Please don't. One directory is much easier to work with. At least\n> don't split the Makefile. Also moving files makes \"git log \"\n> stop at the rename.\n> \nBy \"don't split the Makefile\", do mean, \"Don't use recursive make\"?\n\nI'm fine with that (and if you look at my patch, I \"include\nscm/Makefile\" to do just that), but if you mean \"keep only a top-level\nMakefile\", well, I think that continues the problem of \"there is too\nmuch stuff going on here\", but I can be persuaded otherwise.\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n\n\n"},{"id":"23507","messageId":"7vsllae1ik.fsf@assigned-by-dhcp.cox.net","threadId":"4812","inReplyTo":"20060709222308.GA4153@h4x0r5.com","subject":"Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-10T00:39:47Z","receivedAt":"2006-07-10T00:39:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan Anderson writes:\n\n> Comments on a way to make the Makefile less repetitive would be\n> appreciated, though.\n\nOne obvious way would be not to have scm/Makefile but have the\ndependencies in the main Makefile to say (the moral equivalent\nof):\n\n\tgit-archimport.perl: scm/git-archimport.perl\n"},{"id":"23514","messageId":"44B1C872.3050807@michonline.com","threadId":"4812","inReplyTo":"7vsllae1ik.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-07-10T03:24:34Z","receivedAt":"2006-07-10T03:24:34Z","isPatch":true,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"Junio C Hamano wrote:\n> Ryan Anderson writes:\n>\n> \n>> Comments on a way to make the Makefile less repetitive would be\n>> appreciated, though.\n>> \n>\n> One obvious way would be not to have scm/Makefile but have the\n> dependencies in the main Makefile to say (the moral equivalent\n> of):\n>\n> \tgit-archimport.perl: scm/git-archimport.perl\n> \nI think that doing that means I still need to duplicate the actual\nbuild rules, which is what I was hoping to avoid, as they encode all the\nmagic \"path replacement\" logic in multiple places.\n\nOn the other hand, I can fix *that*, if I break the ability to run in\nthe build directory, which is bad in its own way. (Fixing the tests\nshould be a matter of adapting the test library slightly, I think.)\n\nFor the time being, I'm going with ugly, but less disruptive, and I'm\nwilling/planning on revisiting it when things shake out a bit more.\n\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n\n\n"},{"id":"23533","messageId":"20060710124525.54ecaeab.tihirvon@gmail.com","threadId":"4812","inReplyTo":"44B19D42.6030701@michonline.com","subject":"Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-07-10T09:45:25Z","receivedAt":"2006-07-10T09:45:25Z","isPatch":true,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"Ryan Anderson wrote:\n\n> By \"don't split the Makefile\", do mean, \"Don't use recursive make\"?\n> \n> I'm fine with that (and if you look at my patch, I \"include\n> scm/Makefile\" to do just that), but if you mean \"keep only a top-level\n> Makefile\", well, I think that continues the problem of \"there is too\n> much stuff going on here\", but I can be persuaded otherwise.\n\nRecursive make is a horrible hack. Splitting Makefile to smaller chunks\nwhich would be included in the top level Makefile is almost as bad. You\ncan't cd to subdirectory and run make there and you have to prefix all\nfiles with \"subdir/\".\n\nIf you really want to make Makefile shorter just move all the platform\nspecific stuff to a configure script.\n\n-- \nhttp://onion.dynserv.net/~timo/\n"}]}