On 5 July 2013 09:04, Matthieu Moy 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
>> #
>> +# To build and test:
>> +#
>> +# make:
>> +# bin-wrapper/git m
>> 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
> 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
> 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
> 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
> 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 acces
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
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 h
> +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];
> + }
On 17 June 2013 09:12, Matthieu Moy 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 installed
On 16 June 2013 22:18, Matthieu Moy 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 comment in the Makefile).
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 wrote:
> benoit.per...@ensimag.fr writes:
> How does the "make" Vs "make install" work? How does a developer run the
> tool without installing?
Well it does not
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 wrote:
>
> You could make a Git::MediaWiki.pm module, but installing that would
> significantly complicate the build procedure, and p
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
On 9 June 2013 08:08, Jeff King 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 `git mw pre
Matthieu Moy 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 the
> remote ones,
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 that
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,
18 matches
Mail list logo
