# [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ 11 messages from 2006-07-09 to 2006-07-10. Participants: Ryan Anderson, Johannes Schindelin, Martin Langhoff, Petr Baudis, Timo Hirvonen, Junio C Hamano. Thread: https://gitlist.dev/t/4812 ## Ryan Anderson, 2006-07-09 06:17 Subject: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ Message-ID: <11524258261798-git-send-email-ryan@michonline.com> URL: https://gitlist.dev/e/11524258261798-git-send-email-ryan%40michonline.com ``` Signed-off-by: Ryan Anderson --- This is the first in a series to categorize the source tree a little bit more than it is currently. I figured I'd start with something innocuous, like the SCM interoperability tools. One thing I don't really like is that I had to duplicate the Perl build rule in the subdirectory Makefile, effectively, to restructure it and leave the built files in the root. If we can deprecate "run from the source tree", this can go away. (That requires fixing up a lot of tests, but it's straightforward, at least.) So, flame away! Makefile | 10 ++++++---- scm/Makefile | 20 ++++++++++++++++++++ git-archimport.perl => scm/git-archimport.perl | 0 .../git-cvsexportcommit.perl | 0 git-cvsimport.perl => scm/git-cvsimport.perl | 0 git-cvsserver.perl => scm/git-cvsserver.perl | 0 git-p4import.py => scm/git-p4import.py | 0 git-send-email.perl => scm/git-send-email.perl | 0 git-svnimport.perl => scm/git-svnimport.perl | 0 9 files changed, 26 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 202f261..e7f5b48 100644 --- a/Makefile +++ b/Makefile @@ -130,11 +130,10 @@ SCRIPT_SH = \ git-lost-found.sh git-quiltimport.sh SCRIPT_PERL = \ - git-archimport.perl git-cvsimport.perl git-relink.perl \ + git-relink.perl \ git-shortlog.perl git-rerere.perl \ - git-annotate.perl git-cvsserver.perl \ - git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \ - git-send-email.perl + git-annotate.perl \ + git-mv.perl SCRIPT_PYTHON = \ git-merge-recursive.py @@ -176,6 +175,9 @@ BUILT_INS = git-log$X git-whatchanged$X git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X \ git-fmt-merge-msg$X + +include scm/Makefile + # what 'all' will build and 'install' will install, in gitexecdir ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) diff --git a/scm/Makefile b/scm/Makefile new file mode 100644 index 0000000..0ce205b --- /dev/null +++ b/scm/Makefile @@ -0,0 +1,20 @@ + +SCM_PERL_BASE = \ + git-archimport.perl \ + git-cvsimport.perl \ + git-cvsexportcommit.perl \ + git-cvsserver.perl \ + git-svnimport.perl \ + git-send-email.perl + +SCRIPTS+=$(patsubst %.perl,%,$(SCM_PERL_BASE)) + +$(patsubst %.perl,%,$(SCM_PERL_BASE)) : % : scm/%.perl + rm -f $@ $@+ + sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \ + -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \ + $^ >$@+ + chmod +x $@+ + mv $@+ $@ + + diff --git a/git-archimport.perl b/scm/git-archimport.perl similarity index 100% rename from git-archimport.perl rename to scm/git-archimport.perl diff --git a/git-cvsexportcommit.perl b/scm/git-cvsexportcommit.perl similarity index 100% rename from git-cvsexportcommit.perl rename to scm/git-cvsexportcommit.perl diff --git a/git-cvsimport.perl b/scm/git-cvsimport.perl similarity index 100% rename from git-cvsimport.perl rename to scm/git-cvsimport.perl diff --git a/git-cvsserver.perl b/scm/git-cvsserver.perl similarity index 100% rename from git-cvsserver.perl rename to scm/git-cvsserver.perl diff --git a/git-p4import.py b/scm/git-p4import.py similarity index 100% rename from git-p4import.py rename to scm/git-p4import.py diff --git a/git-send-email.perl b/scm/git-send-email.perl similarity index 100% rename from git-send-email.perl rename to scm/git-send-email.perl diff --git a/git-svnimport.perl b/scm/git-svnimport.perl similarity index 100% rename from git-svnimport.perl rename to scm/git-svnimport.perl -- 1.4.1.gc473b-dirty ``` ## Johannes Schindelin, 2006-07-09 14:31 Subject: Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0607091631000.29667%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <11524258261798-git-send-email-ryan@michonline.com> ``` Hi, On Sun, 9 Jul 2006, Ryan Anderson wrote: > If we can deprecate "run from the source tree", this can go away. You would make yours truly very sad. Besides, for the tests we need the functionality anyway. Ciao, Dscho ``` ## Martin Langhoff, 2006-07-09 21:26 Subject: Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ Message-ID: <46a038f90607091426u5a6ea328h2090a876e51725ce@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90607091426u5a6ea328h2090a876e51725ce%40mail.gmail.com In-Reply-To: <11524258261798-git-send-email-ryan@michonline.com> ``` On 7/9/06, Ryan Anderson wrote: > This is the first in a series to categorize the source tree a little bit more > than it is currently. Given that you title it RFC, I guess it hasn't been discussed before. I personally don't see much benefit from the move/rename. The tree is not so large, the SCM import/export utilities are a single file each and their names are quite clear. Having /contrib is more an issue of marking utilities there as 'new, experimental, unsupported', and the assumption is that when something matures it moves out of /contrib. So I have to ask... what are the expected benefits of the move? In any case, use /interop instead. /scm in the tree of an SCM could be anything ;-) martin ``` ## Petr Baudis, 2006-07-09 22:13 Subject: Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ Message-ID: <20060709221326.GU29115@pasky.or.cz> URL: https://gitlist.dev/e/20060709221326.GU29115%40pasky.or.cz In-Reply-To: <46a038f90607091426u5a6ea328h2090a876e51725ce@mail.gmail.com> ``` Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter where Martin Langhoff said that... > So I have to ask... what are the expected benefits of the move? I've been meaning to do something like this for some time already; my itch have been the builtins. The tree size _is_ getting out of hand and a little more categorization of the sources would certainly help. Although I'd take a different approach: libgit/ builtin/ standalone/ scripts/ > In any case, use /interop instead. /scm in the tree of an SCM could be > anything ;-) I agree on this point. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Snow falling on Perl. White noise covering line noise. Hides all the bugs too. -- J. Putnam ``` ## Johannes Schindelin, 2006-07-09 22:21 Subject: Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0607100018380.29667%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <20060709221326.GU29115@pasky.or.cz> ``` Hi, On Mon, 10 Jul 2006, Petr Baudis wrote: > Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter > where Martin Langhoff said that... > > So I have to ask... what are the expected benefits of the move? > > I've been meaning to do something like this for some time already; my > itch have been the builtins. The tree size _is_ getting out of hand and > a little more categorization of the sources would certainly help. Funny. I thought the builtin-* prefix, and the *.sh and *.perl extensions were there for the sake of categorization. And I disagree on the "out of hand" thing. Ciao, Dscho ``` ## Ryan Anderson, 2006-07-09 22:23 Subject: Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ Message-ID: <20060709222308.GA4153@h4x0r5.com> URL: https://gitlist.dev/e/20060709222308.GA4153%40h4x0r5.com In-Reply-To: <20060709221326.GU29115@pasky.or.cz> ``` On Mon, Jul 10, 2006 at 12:13:26AM +0200, Petr Baudis wrote: > Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter > where Martin Langhoff said that... > > So I have to ask... what are the expected benefits of the move? > > I've been meaning to do something like this for some time already; my > itch have been the builtins. The tree size _is_ getting out of hand and > a little more categorization of the sources would certainly help. That's what I was thinking, as well, basically. I started with the "scm interop" tools because they should be the least controversial to move around. > Although I'd take a different approach: > > libgit/ > builtin/ > standalone/ > scripts/ > > > In any case, use /interop instead. /scm in the tree of an SCM could be > > anything ;-) > > I agree on this point. Very good point. So these seem obvious to me: libgit/ (maybe just lib/?) builtin/ interop/ I'm less sure of the rest, but I'll poke at doing the above for the moment, and worry about the rest later. Comments on a way to make the Makefile less repetitive would be appreciated, though. -- Ryan Anderson sometimes Pug Majere ``` ## Timo Hirvonen, 2006-07-09 22:34 Subject: Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ Message-ID: <20060710013405.54fbe6bb.tihirvon@gmail.com> URL: https://gitlist.dev/e/20060710013405.54fbe6bb.tihirvon%40gmail.com In-Reply-To: <20060709221326.GU29115@pasky.or.cz> ``` Petr Baudis wrote: > I've been meaning to do something like this for some time already; my > itch have been the builtins. The tree size _is_ getting out of hand and > a little more categorization of the sources would certainly help. > Although I'd take a different approach: > > libgit/ > builtin/ > standalone/ > scripts/ Please don't. One directory is much easier to work with. At least don't split the Makefile. Also moving files makes "git log " stop at the rename. -- http://onion.dynserv.net/~timo/ ``` ## Ryan Anderson, 2006-07-10 00:20 Subject: Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ Message-ID: <44B19D42.6030701@michonline.com> URL: https://gitlist.dev/e/44B19D42.6030701%40michonline.com In-Reply-To: <20060710013405.54fbe6bb.tihirvon@gmail.com> ``` Timo Hirvonen wrote: > Petr Baudis wrote: > > >> I've been meaning to do something like this for some time already; my >> itch have been the builtins. The tree size _is_ getting out of hand and >> a little more categorization of the sources would certainly help. >> Although I'd take a different approach: >> >> libgit/ >> builtin/ >> standalone/ >> scripts/ >> > > Please don't. One directory is much easier to work with. At least > don't split the Makefile. Also moving files makes "git log " > stop at the rename. > By "don't split the Makefile", do mean, "Don't use recursive make"? I'm fine with that (and if you look at my patch, I "include scm/Makefile" to do just that), but if you mean "keep only a top-level Makefile", well, I think that continues the problem of "there is too much stuff going on here", but I can be persuaded otherwise. -- Ryan Anderson sometimes Pug Majere ``` ## Junio C Hamano, 2006-07-10 00:39 Subject: Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ Message-ID: <7vsllae1ik.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vsllae1ik.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060709222308.GA4153@h4x0r5.com> ``` Ryan Anderson writes: > Comments on a way to make the Makefile less repetitive would be > appreciated, though. One obvious way would be not to have scm/Makefile but have the dependencies in the main Makefile to say (the moral equivalent of): git-archimport.perl: scm/git-archimport.perl ``` ## Ryan Anderson, 2006-07-10 03:24 Subject: Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ Message-ID: <44B1C872.3050807@michonline.com> URL: https://gitlist.dev/e/44B1C872.3050807%40michonline.com In-Reply-To: <7vsllae1ik.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Ryan Anderson writes: > > >> Comments on a way to make the Makefile less repetitive would be >> appreciated, though. >> > > One obvious way would be not to have scm/Makefile but have the > dependencies in the main Makefile to say (the moral equivalent > of): > > git-archimport.perl: scm/git-archimport.perl > I think that doing that means I still need to duplicate the actual build rules, which is what I was hoping to avoid, as they encode all the magic "path replacement" logic in multiple places. On the other hand, I can fix *that*, if I break the ability to run in the build directory, which is bad in its own way. (Fixing the tests should be a matter of adapting the test library slightly, I think.) For the time being, I'm going with ugly, but less disruptive, and I'm willing/planning on revisiting it when things shake out a bit more. -- Ryan Anderson sometimes Pug Majere ``` ## Timo Hirvonen, 2006-07-10 09:45 Subject: Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/ Message-ID: <20060710124525.54ecaeab.tihirvon@gmail.com> URL: https://gitlist.dev/e/20060710124525.54ecaeab.tihirvon%40gmail.com In-Reply-To: <44B19D42.6030701@michonline.com> ``` Ryan Anderson wrote: > By "don't split the Makefile", do mean, "Don't use recursive make"? > > I'm fine with that (and if you look at my patch, I "include > scm/Makefile" to do just that), but if you mean "keep only a top-level > Makefile", well, I think that continues the problem of "there is too > much stuff going on here", but I can be persuaded otherwise. Recursive make is a horrible hack. Splitting Makefile to smaller chunks which would be included in the top level Makefile is almost as bad. You can't cd to subdirectory and run make there and you have to prefix all files with "subdir/". If you really want to make Makefile shorter just move all the platform specific stuff to a configure script. -- http://onion.dynserv.net/~timo/ ```