Benoît Person <> 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/ 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to