Benoît Person <benoit.per...@ensimag.fr> writes: >> Two possible alternatives: >> >> - Is there a reason you would not want to "install" whatever Perl >> modules you want to "use" via GITPERLLIB mechanism to >> ../../perl/blib/lib? > If we are making modifications to Git/Mediawiki.pm or even git-mw.perl > / git-remote-mediawiki.perl, installing them without proper testing > beforehand seems wrong.
That's not "installing" (i.e. not "make install"), just a copy within the source tree. Same as what's done in Git's toplevel. > But it was weird to work on that in this serie which initial goal was > to add a preview tool for git-remote-mediawiki and ended up adding a > new perl package, a new 'git mw' command which handles subcommands, > ... That's life ;-). Refactoring as you add new features is really important (remember your first attempt with a huge copy/paste ... nice for prototyping, but not acceptable in the long run). > In the end, this patch could be removed from the serie since it is > self-contained : it is not used by 3/5, 4/5, and 5/5. Well, it's the one that makes them usable without "make install"-ing, so I think it should remain part of the series. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
