git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Lea Wiemann <lewiemann@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2] gitweb: use Git.pm, and use its parse_rev method for git_get_head_hash
Date: Sun, 01 Jun 2008 14:33:56 -0700	[thread overview]
Message-ID: <7vy75oalh7.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 4842C3F1.5000001@gmail.com

Lea Wiemann <lewiemann@gmail.com> writes:

> Junio C Hamano wrote:
>> With this on top of your parse_rev patch (I used v2 but I do not think v3
>> changes the situation in any way), you seem to have broken t9500.
>>
>> [...] I suspect that you are not using your own Git in the build tree in
>> your test, but an already installed one.
>
> That was indeed the case, thanks for pointing it out!
>
> However, after applying my two patches and your patch on a pristine
> current git.git clone, I still don't get an error...

If you applied the "this on top of yours" fix, you shouldn't have seen any
breakage.

The breakage was not about what you did in Git.pm, but about adding "use
Git" in gitweb.perl but without arranging it to find Git.pm (I do not have
any git installed in usual places on my machine, and I strip the directory
I keep my git installation out of my $PATH when running tests, to make
sure "make test" can bootstrap itself without first installing).

> How about putting this into test-lib.sh?  There are more tests (like
> my new Git.pm test suite) that will need it, so setting it up in a
> central place would probably more convenient and prevent future
> problems of this sort.

Sure, I think that would be sensible.

> If PERL5LIB already contains paths, can we just discard them, or
> should we preserve them?

It would be best to keep the existing one but make ours the first thing to
be found, so that we will be sure that we test the one we just built.

> Since perl/Makefile only copies Git.pm to blib/lib/Git.pm, we could
> also set the path to ../../perl, which would prevent us from
> accidentally running tests against an old version of Git.pm (because
> we haven't run cd perl; make before).  And perhaps add a comment to
> perl/Makefile about this, in case someone wants to change the build
> process in the future. Or is there some reason why this would be a bad
> idea?

I think it is a bad idea.  In principle we should be testing what we just
built and will install; even if currently the "building procedure" for
blib/lib/Git.pm may happen to be bit-for-bit copy of the original, that is
just by accident and not something we would want to rely on.

  reply	other threads:[~2008-06-01 21:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-30 23:00 [PATCH] gitweb: use Git.pm, and use its parse_rev method for git_get_head_hash Lea Wiemann
2008-05-30 23:03 ` Lea Wiemann
2008-05-31  9:40   ` Jakub Narebski
2008-05-31 12:39     ` Lea Wiemann
2008-06-01 22:19       ` Jakub Narebski
2008-06-02  5:35         ` Junio C Hamano
2008-06-02  9:29         ` Petr Baudis
2008-06-02 21:32           ` Jakub Narebski
2008-06-02 22:31             ` Lea Wiemann
2008-05-31 13:04 ` Petr Baudis
2008-05-31 14:19   ` [PATCH v2] " Lea Wiemann
2008-05-31 14:34     ` Lea Wiemann
2008-06-01  8:23     ` Junio C Hamano
2008-06-01 15:44       ` Lea Wiemann
2008-06-01 21:33         ` Junio C Hamano [this message]
2008-06-01 22:16           ` [PATCH] test-lib.sh: set PERL5LIB instead of GITPERLLIB Lea Wiemann
2008-06-02  5:17             ` Junio C Hamano
2008-06-02 14:08               ` Lea Wiemann
2008-06-02 14:13                 ` [PATCH v2] " Lea Wiemann
2008-06-02 20:01                   ` Junio C Hamano
2008-06-02 22:19                     ` Lea Wiemann
2008-06-03  0:20               ` [PATCH] " Lea Wiemann
2008-06-01 23:18     ` [PATCH v2] gitweb: use Git.pm, and use its parse_rev method for git_get_head_hash Lea Wiemann

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=7vy75oalh7.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=lewiemann@gmail.com \
    /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).