Hello,
We are another team from Ensimag (Célestin MATTE Benoit PERSON) who
will contribute to Git and more specifically to Git-Mediawiki for our
one-month school project - and possibly more. We already have a couple
of basic patches in local and will submit them in the upcoming days.
After that,
The major drawback of using perl `constant` is the fact that they do
not interpolate like variables in most of the contexts (those who
automatically quotes barewords). Like said on Perl Monks here [1], you
have to do some tricks depending on the context in which you're
using the constant and
Matthieu Moy matthieu@grenoble-inp.fr writes:
Same question here. I'd expect git mw preview in a mediawiki workflow
to do what pdflatex foo evince foo.pdf do in a latex workflow: see
in rendered form what I've been doing.
In a latex flow, if I want to see how my local changes merge with
On 9 June 2013 08:08, Jeff King p...@peff.net wrote:
I also wonder if it would be useful to be able to specify not only files
in the filesystem, but also arbitrary blobs. So in 4b above, you could
git mw preview origin:page.mw to see the rendered version of what
upstream has done.
Hum, so
Well, I think next step would be to replace all those calls with
Git.pm `command`, `command_oneline` and `config``which take an array
of arguments after the command. In the preview tool we use those but
I don't know if we will find the time to clean that up too in
git-remote-mediawiki :) .
Don't
The V2 is on the launchpad but I am still struggling with the code
factoring between git-mw.perl and git-remote-mediawiki.perl :/ .
On 9 June 2013 08:08, Jeff King p...@peff.net wrote:
You could make a Git::MediaWiki.pm module, but installing that would
significantly complicate the build
The V3 is ready, but I am still not sure about what is the best way to
do it for this issue though.
On 13 June 2013 15:01, Matthieu Moy matthieu@grenoble-inp.fr wrote:
benoit.per...@ensimag.fr writes:
How does the make Vs make install work? How does a developer run the
tool without
On 16 June 2013 22:18, Matthieu Moy matthieu@grenoble-inp.fr wrote:
benoit.per...@ensimag.fr writes:
changes from the V2:
- Add a way to test, without installation, code that uses GitMediawiki.pm.
This still needs to be documented, even very quickly, somewhere in the
code (e.g a
On 17 June 2013 09:12, Matthieu Moy matthieu@grenoble-inp.fr wrote:
Also, it seems to be only part of the solution. With your change, from
contrib/mw-to-git/ and after running only make,
./git-mw takes the installed version of GitMediawiki.pm in priority
../../bin-wrappers/git takes the
+sub split_email_list {
+my(@list) = @_;
+my @tmp;
+my @emails;
+ for (my $i = 0; $i = $#list; $i++) {
+ if ($list[$i] =~ /,/) {
+ @emails = split(/,/, $list[$i]);
+ } else {
+ @emails = $list[$i];
+ }
+
Ok, thanks for all the reviews,
Final version (I hope :) ) will come when all the mediawiki patches
will have graduated to 'master' then.
Benoit Person
--
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
Oops, so sorry :/
It's defintely doable since the lowercase 'git' is only a bin-wrapper
for git to ease development in contrib/mw-to-git/ .
Junio, Matthieu : should I resend a new version of my serie which
renames the 'git' (lowercase) file into something like 'git-dev' ?
(some comments directly
Hmph. Does it even need to be in-tree then? Is it insufficient to
run ../../git from that directory instead?
Well, the fact is we use Perl packages now (Git.pm and
Git::Mediawiki.pm in contrib/mw-to-git/Git/). The way we build perl
scripts in the toplevel's Makefile makes those packages
As far as I can tell, the only real reason why you need this and
cannot use ../../bin-wrappers/git directly is because the GITPERLLIB
it gives you only points at ../../perl/blib/lib and not this
directory.
Plus (forgot to mention it in the other mail :/ ) it enables us to not
copy git-mw and
GIT_ROOT_DIR=../../..
GIT_EXEC_PATH=$(cd $(dirname $0) cd ${GIT_ROOT_DIR} pwd)
GIT_MEDIAWIKI=$GIT_EXEC_PATH/contrib/mw-to-git
PATH=$GIT_MEDIAWIKI/contrib/mw-to-git:$PATH
GPLEXTRA=$GIT_MEDIAWIKI/contrib/mw-to-git
exec ${GIT_EXEC_PATH}/bin-wrappers/git $@
Should I do that in a reroll ?
Do we want to add that ':' unconditionally? Could GITPERLLIB be
empty?
For now, GITPERLLIB is only used in that kind of statements:
use lib (split(/:/, $ENV{GITPERLLIB} || ... ));
The trailing ':' does not really matter, split will ignore it.
With the current codebase, I think it's nicer to
For now, GITPERLLIB is only used in that kind of statements:
use lib (split(/:/, $ENV{GITPERLLIB} || ... ));
The trailing ':' does not really matter, split will ignore it.
That may be true with the current use, but For now leaves funny
taste, doesn't it?
definitely. For me, the issue was
On 5 July 2013 09:04, Matthieu Moy matthieu@grenoble-inp.fr wrote:
benoit.per...@ensimag.fr writes:
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -2,6 +2,12 @@
# Copyright (C) 2013
# Matthieu Moy matthieu@imag.fr
#
+# To build and test:
+#
+#
18 matches
Mail list logo
