git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Benoît Person" <benoit.person@ensimag.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Celestin Matte <celestin.matte@ensimag.fr>,
	Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Subject: Re: [PATCH v6 2/5] git-remote-mediawiki: new git bin-wrapper for developement
Date: Thu, 27 Jun 2013 20:53:16 +0200	[thread overview]
Message-ID: <CAETqRCjZdv-_V3jmhjxZj+_XU7AKRvMZ3ojo7=yW3m846F4E1w@mail.gmail.com> (raw)
In-Reply-To: <7vr4fnsafy.fsf@alter.siamese.dyndns.org>

> 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-remote-mediawiki at each "make" and stop us from
polluting the toplevel directory with those two scripts during
development.

> 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.

>    Perhaps it will interfere with the real
>    installation step in ../../perl/Makefile?
I don't think so, but I am not an expert on what's going on in
../../perl/Makefile.

>    If that is the case,
>    then it is not a good idea, but otherwise, that would let you use
>    ../../bin-wrappers/git as-is.
>
>  - Perhaps we could do:
>
>         GITPERLLIB="${GPLEXTRA+$GPLEXTRA:}@@BUILD_DIR@@/perl/blib/lib"
>
>    in wrap-for-bin.sh, so that your instruction can become
>
>         GPLEXTRA=$(pwd) ../../bin-wrappers/git whatever-mw-thing
>
>    and you do not have to have this file?  We would also need to
>    "unset GPLEXTRA" at the beginning of test-lib.sh if we were to do
>    this.


> How does a developer (or user) use this script?  From your Makefile
> (e.g. "make test")?  Manually following some written instruction?
> In either case, the latter option feels a lot more sensible
> alternative without having to maintain this extra copy of wrap-for-bin
> that can easily go out of sync.
A developer uses it like any bin-wrapper : bin-wrapper/git mw preview
for instance. He can add it to its path while working on the scripts
etc ...

The best way to do it would be to factorise those new use cases
(adding new elements in $GITPERLLIB and $PATH) in the code that
generate bin-wrappers from wrap-for-bin.sh I think.

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,
...

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.

Benoit

  parent reply	other threads:[~2013-06-27 18:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-27 17:37 [PATCH v6 0/5] git-remote-mediawiki: new tool to preview local changes without pushing benoit.person
2013-06-27 17:37 ` [PATCH v6 1/5] git-remote-mediawiki: Introduction of Git::Mediawiki.pm benoit.person
2013-06-27 17:37 ` [PATCH v6 2/5] git-remote-mediawiki: new git bin-wrapper for developement benoit.person
2013-06-27 17:57   ` Junio C Hamano
2013-06-27 18:47     ` Matthieu Moy
2013-06-27 18:53     ` Benoît Person [this message]
2013-06-27 22:21       ` Matthieu Moy
2013-06-29 11:09         ` Benoît Person
2013-07-01  7:46           ` Matthieu Moy
2013-06-27 17:37 ` [PATCH v6 3/5] git-remote-mediawiki: factoring code between git-remote-mediawiki and Git::Mediawiki benoit.person
2013-06-27 17:37 ` [PATCH v6 4/5] git-remote-mediawiki: Adding git-mw command benoit.person
2013-06-27 17:37 ` [PATCH v6 5/5] git-remote-mediawiki: Add preview subcommand into git mw benoit.person

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAETqRCjZdv-_V3jmhjxZj+_XU7AKRvMZ3ojo7=yW3m846F4E1w@mail.gmail.com' \
    --to=benoit.person@ensimag.fr \
    --cc=celestin.matte@ensimag.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=matthieu.moy@grenoble-inp.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).