* Re: There you have it. Git.pm breaks pull.
From: Junio C Hamano @ 2006-07-03 4:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607030633120.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Can't locate Git.pm in @INC (@INC contains:
> /home/gene099/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
> /usr/lib/perl5/5.8.0/i586-linux-thread-multi /usr/lib/perl5/5.8.0
> /usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl .) at
> ./git-fmt-merge-msg line 14.
> BEGIN failed--compilation aborted at ./git-fmt-merge-msg line 14.
You need to set up your PERL5LIB appropriately, in addition to
what you used to set: PATH and GIT_EXEC_PATH. Something like
this, perhaps:
PERL5LIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git
GIT_EXEC_PATH=`pwd`
PATH=`pwd`:/usr/bin:/bin
export GIT_EXEC_PATH PATH PERL5LIB
^ permalink raw reply
* There you have it. Git.pm breaks pull.
From: Johannes Schindelin @ 2006-07-03 4:35 UTC (permalink / raw)
To: git
Hi,
I do not install git, but run it in place. And now git-pull, the core of
git, is broken.
Can't locate Git.pm in @INC (@INC contains:
/home/gene099/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
/usr/lib/perl5/5.8.0/i586-linux-thread-multi /usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl .) at
./git-fmt-merge-msg line 14.
BEGIN failed--compilation aborted at ./git-fmt-merge-msg line 14.
I have to run for work, but next thing I'll do with git is rewrite
git-fmt-merge-msg in C.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] send-email: Use setlocale in addition to $ENV{LC_ALL} to set locale
From: Junio C Hamano @ 2006-07-03 2:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Eric Wong
In-Reply-To: <20060621104941.GB15748@localdomain>
I was reviewing old log and noticed this topic has never been
resolved. Your proposal was to use POSIX::setlocale(), and
Eric's counter-proposal was to mimic what 822-date script does,
doing it by hand without mucking with locales, and the
discussion seemed to have died there. Does this still need to
be addressed?
My gut feeling is that it would probably be less problematic if
we do not muck with locales at all (so drop POSIX::strftime as
well).
So maybe something like this (totally untested)?
-- >8 --
[PATCH] do not use locale specific strftime when preparing 2822 date
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-send-email.perl b/git-send-email.perl
index c5d9e73..bc42761 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -23,8 +23,43 @@ use Getopt::Long;
use Data::Dumper;
# most mail servers generate the Date: header, but not all...
-$ENV{LC_ALL} = 'C';
-use POSIX qw/strftime/;
+sub format_2822_time {
+ my ($time) = @_;
+ my @localtm = localtime($time);
+ my @gmttm = gmtime($time);
+ my $localmin = $localtm[1] + $localtm[2] * 60;
+ my $gmtmin = $gmttm[1] + $gmttm[2] * 60;
+ if ($localtm[0] != $gmttm[0]) {
+ die "local zone differs from GMT by a non-minute interval\n";
+ }
+ if ((($gmttm[6] + 1) % 7) == $localtm[6]) {
+ $localmin += 1440;
+ } elsif ((($gmttm[6] - 1) % 7) == $localtm[6]) {
+ $localmin -= 1440;
+ } elsif ($gmttm[6] != $localtm[6]) {
+ die "local time offset greater than or equal to 24 hours\n";
+ }
+ my $offset = $localmin - $gmtmin;
+ my $offhour = $offset / 60;
+ my $offmin = abs($offset % 60);
+ if (abs($offhour) >= 24) {
+ die ("local time offset greater than or equal to 24 hours\n");
+ }
+
+ return sprintf("%s, %2d %s %d %02d:%02d:%02d %s%02d%02d",
+ qw(Sun Mon Tue Wed Thu Fri Sat)[$localtm[6]],
+ $localtm[3],
+ qw(Jan Feb Mar Apr May Jun
+ Jul Aug Sep Oct Nov Dec)[$localtm[4]],
+ $localtm[5]+1900,
+ $localtm[2],
+ $localtm[1],
+ $localtm[0],
+ ($offset >= 0) ? '+' : '-',
+ abs($offhour),
+ $offmin,
+ );
+}
my $have_email_valid = eval { require Email::Valid; 1 };
my $smtp;
@@ -371,7 +405,7 @@ sub send_message
my @recipients = unique_email_list(@to);
my $to = join (",\n\t", @recipients);
@recipients = unique_email_list(@recipients,@cc,@bcclist);
- my $date = strftime('%a, %d %b %Y %H:%M:%S %z', localtime($time++));
+ my $date = format_2822_time($time++);
my $gitversion = '@@GIT_VERSION@@';
if ($gitversion =~ m/..GIT_VERSION../) {
$gitversion = `git --version`;
^ permalink raw reply related
* [RFC/PATCH] consistently try VISUAL, EDITOR and vi in this order.
From: Junio C Hamano @ 2006-07-03 2:47 UTC (permalink / raw)
To: git
git grep -e VISUAL -e EDITOR revealed this inconsistency. All
other commands seem to check VISUAL and then EDITOR as they should.
---
diff --git a/git-send-email.perl b/git-send-email.perl
index c5d9e73..7b81962 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -222,8 +256,7 @@ GIT: for the patch you are writing.
EOT
close(C);
- my $editor = $ENV{EDITOR};
- $editor = 'vi' unless defined $editor;
+ my $editor = $ENV{VISUAL} || $ENV{EDITOR} || 'vi';
system($editor, $compose_filename);
open(C2,">",$compose_filename . ".final")
^ permalink raw reply related
* contrib/ status
From: Junio C Hamano @ 2006-07-03 2:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vslljwiat.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ... the
> things under contrib/ are not part of git.git but are there only
> for convenience....
This reminds me of something quite different. I am getting an
impression that enough people have been helped by git-svn and it
might be a good idea to have it outside contrib/ area.
OTOH I haven't seen much interest in contrib/colordiff, now
Johannes's built-in "diff --color" is in. So if people do not
mind, I'd like to drop it.
^ permalink raw reply
* Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
From: Junio C Hamano @ 2006-07-03 2:09 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e89ock$gks$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> I thought this stuff was "opt-in", but make rpm now requires
>> autoconf?
>
> Ooops. No, git RPM wouldn't need autoconf, neither building git from *.spec
> file or SRPM.
I had an impression that your spec.in change made it required.
It is still somewhat dubious to me if we can keep this "opt-in".
I noticed that it at least lacks a few extra commands to "clean"
target of the main Makefile, and adding them by itself is not so
bad, but who knows what else it would bring in when the series
finishes. I would not be surprised if we start touching *.c and
*.h files with new autoconf-compatible "#ifdef HAVE_XXX" and at
that point I will say "I told you so".
I am not opposed to giving an alternative, semi-automated way to
edit config.mak to the users, and if that is our goal, we should
ship the configure script in the source tarball at least, and
probably we should have the configure script in the revisions as
well. Using autoconf is not the goal here -- giving ./configure
as an alternative way to manage config.mak is.
But if we have autoconf scripts _and_ configure script in
revisions, we are talking about version controlling generated
stuff, and I'd like to avoid that at all cost.
Maybe an alternative is to just add configure script in the
source tree _without_ adding any of the autoconf scripts to the
git repository. The users can choose to use that script to
manage config.mak but do not have to. And I do not mind getting
occasional updates to the configure script in the source tree,
and I do not care if you build it by hand or use autoconf to
generate it, as long as the configure script is readable,
debuggable and maintainable.
The source to generate that configure script might be autoconf
scripts and you would want to version control that. That is
fine but I think that would be a separate project of yours, and
you may call that the git-build-config project. And I do not
mind hosting that somewhere under contrib/ area in the git
repository in order to give it wider exposure.
That would end up in the same situation as having the source and
generated files under the version control, but I think at the
philosophical level the two are vastly different, in that the
things under contrib/ are not part of git.git but are there only
for convenience. I will not be the one who is responsible to
run autoconf in there every time we make changes to the system
and propagate the changes to the main configure script. The
configure script generated by the end user in contrib/autoconf
may not match the toplevel configure script (the end user may
have different version of autoconf, for example) but that is not
a bug, as long as the toplevel configure script, which might be
output by an older version of autoconf, works correctly.
The above assumes that the configure script generated by your
autoconf script is readable and maintainable at all. Otherwise
it would not make any sense to have configure under version
control.
^ permalink raw reply
* Re: Making perl scripts include the correct Git.pm
From: Junio C Hamano @ 2006-07-03 1:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7v64if1rop.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> so this is my attempt to summarize it:
>
> Ah, our message crossed -- thanks for summarizing it. I do not
> particularly like any of the solution so far, but maybe the
> patch I just sent out to "do the normal thing unless we are
> running tests" might be the right thing to do.
I see you caught Merlyn so I decided the patch I sent earlier as
a tentative fix and merged the series in "next". We should be
able to fix Perly problems in-tree while we have his attention
;-).
Rene's merge-bases fix is also in "next". Hopefully this would
make merge-recursive work by Alex and Johannes go smoother?
On the other front, I applied the --remove-empty --parents fix
by Linus to "master". Since this broke gitk and qgit it might
warrant a 1.4.1.1 hotfix.
^ permalink raw reply
* Re: [PATCH] gitweb: add --full-history to history generation optimization
From: Luben Tuikov @ 2006-07-03 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu060bmxy.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Thanks. I believe I have the same change in "next" already, but
> I had to munge your patches by hand so please holler if there is
> any mistake on my part.
Great, thanks. I took a look at "next" and it looks good.
Luben
^ permalink raw reply
* Why don't you prevent premature creaming from ruining your personal life?
From: Tommy @ 2006-07-03 0:50 UTC (permalink / raw)
To: gord
Halo!
Eliminate this problem and all the anxiety it causes! Become a better male! You'll bring your marriage to new levels of passion and dedication with this.
http://www.kyklopescf.com
Lil boy nah climb ladder to turn big man. Artificial intelligence is no match for natural stupidity Still waters run deep When distrust enters in at the foregate, love goes out at the postern What's good for the goose is good for the gander.
^ permalink raw reply
* Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
From: Jakub Narebski @ 2006-07-03 0:29 UTC (permalink / raw)
To: git
In-Reply-To: <7vodw7zgt2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I thought this stuff was "opt-in", but make rpm now requires
> autoconf?
Ooops. No, git RPM wouldn't need autoconf, neither building git from *.spec
file or SRPM. But rpm targed will need autoconf run, and configure script
packed in tar file (and I think that having configure script in distribution
tar files will be good idea... but perhaps optionally under NO_AUTOCONF
or USE_AUTOCONF).
And I of course forgot about that. So that is only half of a patch...
Besides that patch was meant as example of using autoconf.
Automatic tool (rpmbuild) using automatic tool (./configure script).
P.S. we could distribute ./configure script like we distribute preformatted
documentation, in separate 'configure' branch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
From: Junio C Hamano @ 2006-07-03 0:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200607030202.55919.jnareb@gmail.com>
I thought this stuff was "opt-in", but make rpm now requires
autoconf?
^ permalink raw reply
* Re: [PATCH 1] autoconf: Use autoconf to write installation directories to config.mak.autogen
From: Junio C Hamano @ 2006-07-03 0:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200607030156.50455.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This is beginning of patch series introducing installation configuration
> using autoconf (and no other autotools) to git. The idea is to generate
> config.mak.autogen using ./configure (generated from configure.ac by running
> autoconf) from config.mak.in, so one can use autoconf as an _alternative_ to
> ordinary Makefile, and creating one's own config.mak. Local settings in
> config.mak override generated settings in config.mak.autogen
Thanks. Applied with some trailing whitespace stripped, but not
merged to "next" yet nor pushed out.
^ permalink raw reply
* Re: [PATCH] Empty author may be presented by svn as an empty string or a null value.
From: Junio C Hamano @ 2006-07-03 0:07 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <20060702222100.2863.72633.stgit@h15n1fls34o811.telia.com>
Thanks.
^ permalink raw reply
* Re: Quick merge status updates.
From: Junio C Hamano @ 2006-07-03 0:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607021655440.12404@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 2 Jul 2006, Junio C Hamano wrote:
>> Yuck; that means we would need to have something evil like this.
>
> That's just disgusting.
>
> How about a _much_ simpler approach.
>
> Just make it do
>
> BEGIN { push ENV{'GIT_PERL_EXEC_DIR'}; }
>
> And then simply _require_ that the setup code sets up GIT_PERL_EXEC_DIR.
No, we are not mucking with /usr/bin but are talking about a
directory for platform specific Perl libraries, which we need to
ask Perl at build-time.
And the standard way to say that is to do:
use lib '@@INSTLIBDIR@@';
but that always prepends the directory to the search path, and
the ugly stuff is to allow test scripts to override it when
needed.
^ permalink raw reply
* [PATCH 2] autoconf: Use ./configure script in git *.spec file
From: Jakub Narebski @ 2006-07-03 0:02 UTC (permalink / raw)
To: git
In-Reply-To: <200607030156.50455.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
git.spec.in | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index 8ccd256..1abb7d1 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -74,13 +74,13 @@ Git revision tree visualiser ('gitk')
%setup -q
%build
+%configure
make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} all %{!?_without_docs: doc}
+ all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} mandir=%{_mandir} \
install %{!?_without_docs: install-doc}
(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
--
1.4.0
^ permalink raw reply related
* Re: Making perl scripts include the correct Git.pm
From: Junio C Hamano @ 2006-07-03 0:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060702214012.GI29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> so this is my attempt to summarize it:
Ah, our message crossed -- thanks for summarizing it. I do not
particularly like any of the solution so far, but maybe the
patch I just sent out to "do the normal thing unless we are
running tests" might be the right thing to do.
> (ii) My proposed second solution was to add an autogenerated line to
> the Git's perl scripts saying something like:
>
> use lib ('instlibdir', 'srclibdir');
>
> This fulfills all (D1), (D2) and (D3)
If you have srclibdir after instlibdir, aren't you breaking D2?
And I do not think swapping them is right either. It would
fullfil D1/D2/D3 but I think it has one bad side effect.
Namely, I do not want an installed script, maybe coming from the
vendor, to be affected by whatever unrelated garbage the end
user happens to have on the same path as the one used for
building the module on potentially remote machine, so I would
like to avoid including srclibdir anywhere on the include path
for normal execution.
That is, if I built a binary package in /home/junio/git/git.git
on my machine to be installed in /usr/lib/perl/somewhere, the
users on a multi-user system can be tricked to run random stuff
that happens to be in /home/junio/git/git.git/ directory on
their machine.
^ permalink raw reply
* Re: Quick merge status updates.
From: Linus Torvalds @ 2006-07-03 0:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vejx31sav.fsf@assigned-by-dhcp.cox.net>
On Sun, 2 Jul 2006, Junio C Hamano wrote:
> Yuck; that means we would need to have something evil like this.
That's just disgusting.
How about a _much_ simpler approach.
Just make it do
BEGIN { push ENV{'GIT_PERL_EXEC_DIR'}; }
And then simply _require_ that the setup code sets up GIT_PERL_EXEC_DIR.
Which is usually simple enough to do. For git.c, something like this will
do it, other places you can reach things through can have something
similar.
Linus
---
diff --git a/git.c b/git.c
index ca8961f..e8f25ee 100644
--- a/git.c
+++ b/git.c
@@ -294,6 +294,7 @@ int main(int argc, const char **argv, ch
prepend_to_path(exec_path, strlen(exec_path));
exec_path = git_exec_path();
prepend_to_path(exec_path, strlen(exec_path));
+ setenv(exec_path, "GIT_PERL_EXEC_DIR", 0);
while (1) {
/* See if it's an internal command */
^ permalink raw reply related
* [PATCH 1] autoconf: Use autoconf to write installation directories to config.mak.autogen
From: Jakub Narebski @ 2006-07-02 23:56 UTC (permalink / raw)
To: git
This is beginning of patch series introducing installation configuration
using autoconf (and no other autotools) to git. The idea is to generate
config.mak.autogen using ./configure (generated from configure.ac by running
autoconf) from config.mak.in, so one can use autoconf as an _alternative_ to
ordinary Makefile, and creating one's own config.mak. Local settings in
config.mak override generated settings in config.mak.autogen
This patch includes minimal configure.ac and config.mak.in, so one can set
installation directories using autoconf generated ./configure script
e.g. ./configure --prefix=/usr
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch is to be applied on top of 'next', because to work as intended
(especially for --mandir=<path> option to ./configure) it needs
Allow INSTALL, bindir, mandir to be set in main Makefile
e14421b9aa85f11853a0dacae09498515daab7b8
patch (commit) to be present.
For now the following options do actually something:
$ ./configure
--prefix=<prefix> # [/usr/local]
--exec_prefix=<prefix> # [PREFIX]
--bindir=<bindir> # [EPREFIX/bin]
--datadir=<datadir> # [PREFIX/share]
--mandir=<mandir> # [PREFIX/man]
$ ./configure --help # hardcoded version 1.4.1
QUESTION: how to make autoconf _generate_ correct version string?
Next patch will show how this infrastructure can be used.
.gitignore | 6 ++++++
INSTALL | 9 +++++++++
Makefile | 1 +
config.mak.in | 18 ++++++++++++++++++
configure.ac | 14 ++++++++++++++
5 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 2bcc604..616aa98 100644
--- a/.gitignore
+++ b/.gitignore
@@ -136,4 +136,10 @@ git-core.spec
*.[ao]
*.py[co]
config.mak
+autom4te.cache
+config.log
+config.status
+config.mak.in
+config.mak.autogen
+configure
git-blame
diff --git a/INSTALL b/INSTALL
index f8337e2..28245b3 100644
--- a/INSTALL
+++ b/INSTALL
@@ -13,6 +13,15 @@ that uses $prefix, the built results hav
which are derived from $prefix, so "make all; make prefix=/usr
install" would not work.
+Alternatively you can use autoconf generated ./configure script to
+set up install paths (via config.mak.autogen), so you can write instead
+
+ $ autoconf ;# as yourself if ./configure doesn't exist yet
+ $ ./configure --prefix=/usr ;# as yourself
+ $ make all doc ;# as yourself
+ # make install install-doc ;# as root
+
+
Issues of note:
- git normally installs a helper script wrapper called "git", which
diff --git a/Makefile b/Makefile
index 7dbb883..3c2c257 100644
--- a/Makefile
+++ b/Makefile
@@ -333,6 +333,7 @@ ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
endif
+-include config.mak.autogen
-include config.mak
ifdef WITH_OWN_SUBPROCESS_PY
diff --git a/config.mak.in b/config.mak.in
new file mode 100644
index 0000000..82c9781
--- /dev/null
+++ b/config.mak.in
@@ -0,0 +1,18 @@
+# git Makefile configuration, included in main Makefile
+# @configure_input@
+
+prefix = @prefix@
+exec_prefix = @exec_prefix@
+bindir = @bindir@
+#gitexecdir = @libexecdir@/git-core/
+template_dir = @datadir@/git-core/templates/
+GIT_PYTHON_DIR = @datadir@/git-core/python
+
+mandir=@mandir@
+
+srcdir = @srcdir@
+VPATH = @srcdir@
+
+export exec_prefix mandir
+export srcdir VPATH
+
diff --git a/configure.ac b/configure.ac
new file mode 100644
index 0000000..a54b164
--- /dev/null
+++ b/configure.ac
@@ -0,0 +1,14 @@
+# -*- Autoconf -*-
+# Process this file with autoconf to produce a configure script.
+
+AC_PREREQ(2.59)
+AC_INIT([git], [1.4.1], [git@vger.kernel.org])
+
+AC_CONFIG_SRCDIR([git.c])
+
+config_file=config.mak.autogen
+config_in=config.mak.in
+
+# Output files
+AC_CONFIG_FILES(["${config_file}":"${config_in}"])
+AC_OUTPUT
--
1.4.0
^ permalink raw reply related
* Re: Quick merge status updates.
From: Junio C Hamano @ 2006-07-02 23:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vveqf1v05.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Gaah. You are right.
>
> PERL5LIB does not seem to just do a push (and that was I thought
> why unshift was a way to defeat it) but do something more evil.
> ...
> I thought we killed this showstopper and was hoping now the
> series is mergeable to "next" but apparently not yet X-<.
>
> Sigh....
Yuck; that means we would need to have something evil like this.
-- >8 --
Perly Git: make sure we do test the freshly built one.
We could BEGIN { push @INC, '@@INSTLIBDIR@@'; } but that is not
a good idea for normal execution. The would prevent a
workaround for a user who is trying to override an old, faulty
Git.pm installed on the system path with a newer version
installed under $HOME/.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index 1b23fa1..a9805dd 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -5,7 +5,11 @@ #
# Read .git/FETCH_HEAD and make a human readable merge message
# by grouping branches and tags together to form a single line.
-BEGIN { unshift @INC, '@@INSTLIBDIR@@'; }
+BEGIN {
+ unless (exists $ENV{'RUNNING_GIT_TESTS'}) {
+ unshift @INC, '@@INSTLIBDIR@@';
+ }
+}
use strict;
use Git;
use Error qw(:try);
diff --git a/git-mv.perl b/git-mv.perl
index a604896..5134b80 100755
--- a/git-mv.perl
+++ b/git-mv.perl
@@ -6,7 +6,11 @@ #
# This file is licensed under the GPL v2, or a later version
# at the discretion of Linus Torvalds.
-BEGIN { unshift @INC, '@@INSTLIBDIR@@'; }
+BEGIN {
+ unless (exists $ENV{'RUNNING_GIT_TESTS'}) {
+ unshift @INC, '@@INSTLIBDIR@@';
+ }
+}
use warnings;
use strict;
use Getopt::Std;
diff --git a/t/test-lib.sh b/t/test-lib.sh
index fba0c51..298c6ca 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -206,8 +206,9 @@ PYTHON=`sed -e '1{
PYTHONPATH=$(pwd)/../compat
export PYTHONPATH
}
+RUNNING_GIT_TESTS=YesWeAre
PERL5LIB=$(pwd)/../perl/blib/lib:$(pwd)/../perl/blib/arch/auto/Git
-export PERL5LIB
+export PERL5LIB RUNNING_GIT_TESTS
test -d ../templates/blt || {
error "You haven't built things yet, have you?"
}
^ permalink raw reply related
* Make other men envy you and girls worship you Most efficient products for men
From: Ebony @ 2006-07-02 23:38 UTC (permalink / raw)
To: git
Dear valued customer.
Enhanced male power and unlimited prowess with your girl The best products for the winning guys
Achieve astounding results in bed with these products designed to make any man a winner
http://www.syllabhd.com
A sprat to catch a mackerel. All is for the best in the best of the possible worlds A proverb is a true word. Two things a man should never be angry at: what he can help and what he cannot help
Yuh tel tara and tara tell tara.
^ permalink raw reply
* [PATCH] send-email: do not barf when Term::ReadLine does not like your terminal
From: Junio C Hamano @ 2006-07-02 23:03 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
As long as we do not need to readline from the terminal, we
should not barf when starting up the program. Without this
patch, t9001 test on Cygwin occasionally died with the following
error message:
Unable to get Terminal Size. The TIOCGWINSZ ioctl didn't work. The COLUMNS and LINES environment variables didn't work. The resize program didn't work. at /usr/lib/perl5/vendor_perl/5.8/cygwin/Term/ReadKey.pm line 362.
Compilation failed in require at /usr/lib/perl5/vendor_perl/5.8/Term/ReadLine/Perl.pm line 58.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I do not use send-email myself that often so extra sets of
eyeballs are appreciated.
git-send-email.perl | 18 +++++++++++++++++-
t/t9001-send-email.sh | 11 +++++++----
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index c5d9e73..b04b8f4 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -22,6 +22,17 @@ use Term::ReadLine;
use Getopt::Long;
use Data::Dumper;
+package FakeTerm;
+sub new {
+ my ($class, $reason) = @_;
+ return bless \$reason, shift;
+}
+sub readline {
+ my $self = shift;
+ die "Cannot use readline on FakeTerm: $$self";
+}
+package main;
+
# most mail servers generate the Date: header, but not all...
$ENV{LC_ALL} = 'C';
use POSIX qw/strftime/;
@@ -46,7 +57,12 @@ my $smtp_server;
# Example reply to:
#$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
-my $term = new Term::ReadLine 'git-send-email';
+my $term = eval {
+ new Term::ReadLine 'git-send-email';
+};
+if ($@) {
+ $term = new FakeTerm "$@: going non-interactive";
+}
# Begin by accumulating all the variables (defined above), that we will end up
# needing, first, from the command line:
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index a61da1e..e9ea33c 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -25,10 +25,13 @@ test_expect_success \
git add fake.sendmail
GIT_AUTHOR_NAME="A" git commit -a -m "Second."'
-test_expect_success \
- 'Extract patches and send' \
- 'git format-patch -n HEAD^1
- git send-email -from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" ./0001*txt'
+test_expect_success 'Extract patches' '
+ patches=`git format-patch -n HEAD^1`
+'
+
+test_expect_success 'Send patches' '
+ git send-email -from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
+'
cat >expected <<\EOF
!nobody@example.com!
--
1.4.1.gc92a
^ permalink raw reply related
* Re: qgit idea: interface for cherry-picking
From: Jakub Narebski @ 2006-07-02 22:54 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550607021504l6e7fc8b8ja61f20f630c0f3f@mail.gmail.com>
Marco Costalba wrote:
> What do you think about this:
>
> When dropping the selected commits, instead of creating new commits,
> appears a message box with something like "Do you want to apply the
> commits on top of your current branch or on your working directory?"
>
> Sounds good for you? Or you still prefer the context menu?
> In the latter case, if I have understood correctly, you are limited to
> cherry-pick among branches and/or working directory of the _same_
> repository.
Yes, git-cherry-pick works only between commits in the same repository,
as it use merge (first "simple", i.e. git-read-tree -m -u --aggresive, if
fails tries "automatic" i.e. git-merge-index -o git-merge-one-file -a, then
git-write-tree), as opposed to git-format-patch and git-am or git-apply,
which can work across repositories.
What I really want is "no-commit" of drag'n'dropped, or exported and applied
commits/patches (although interface to cherry-pick would be nice, even if
cherry-pick is limited), so I'd like message box with "Do you want to
commit selected patches?" when dropping commits, or something like that.
Unfortunately git-am doesn't have --no-commit flag, but one could emulate it
with git-reset after git-am a patch, I think.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Quick merge status updates.
From: Junio C Hamano @ 2006-07-02 22:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060702214931.GJ29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sun, Jul 02, 2006 at 11:33:47PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> I tried this:
>>
>> 0. check out the branch that has the Perly git ("pu"). build
>> and install normally to have a perfectly working version
>> accessible on your usual $PATH.
>>
>> 1. apply the patch [1] below to make it use "use lib" instead of
>> "unshift".
>>
>> 2. break perl/Git.pm being built to pretend we introduced a bug
>> in the work in progress by applying the patch [2] below.
>>
>> 3. without installing the broken Git.pm, run "make test", and
>> see a test that uses "git pull" and needs to create a true
>> merge succeed. It tells me that everything including
>> perl/Git.pm is GOOD, and I'd find the breakage only after
>> installing and running the test again.
>
> So, just to clarify and make sure we understand each other perfectly,
> you claim that when skipping (1), (3) _does_ FAIL for you? Because it
> really doesn't for me and I can't see how could it ever fail without
> installing the broken version first.
Gaah. You are right.
PERL5LIB does not seem to just do a push (and that was I thought
why unshift was a way to defeat it) but do something more evil.
With this:
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index 1b23fa1..5d1ae44 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -6,9 +6,11 @@ # Read .git/FETCH_HEAD and make a human
# by grouping branches and tags together to form a single line.
BEGIN { unshift @INC, '@@INSTLIBDIR@@'; }
+use lib '@@INSTLIBDIR@@';
use strict;
use Git;
use Error qw(:try);
+print STDERR "\@INC is @INC\n";
my $repo = Git->repository();
It spits this out:
@INC is /home/junio/git-pu/lib/perl/5.8.8 /opt/git/git.git/t/../perl/blib/lib /opt/git/git.git/t/../perl/blib/arch/auto/Git /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .
So "BEGIN { unshift }" is JUST AS WRONG as "use lib".
I thought we killed this showstopper and was hoping now the
series is mergeable to "next" but apparently not yet X-<.
Sigh....
^ permalink raw reply related
* Re: [PATCH] Git.xs: older perl do not know const char *
From: Junio C Hamano @ 2006-07-02 22:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <20060702215249.GK29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sun, Jul 02, 2006 at 11:53:03AM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
>> Both of these casts _should_ be safe, since you do not want to muck around
>> with the version or the path anyway.
>>
>> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> Acked-by: Petr Baudis <pasky@suse.cz>
>
> It isn't all that great but it seems everything xs does with this is to
> feed it to sv_setpv() which AFAIK copies it around.
Thanks. Already applied but not pushed out yet (I am working on
tracking down unrelated breakage in tests).
^ permalink raw reply
* [PATCH] Empty author may be presented by svn as an empty string or a null value.
From: Robin Rosenberg @ 2006-07-02 22:21 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
---
git-svnimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 38ac732..26dc454 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -534,7 +534,7 @@ sub commit {
my($author_name,$author_email,$dest);
my(@old,@new,@parents);
- if (not defined $author) {
+ if (not defined $author or $author eq "") {
$author_name = $author_email = "unknown";
} elsif (defined $users_file) {
die "User $author is not listed in $users_file\n"
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox