* [PATCH 2/2] gitview: run blame with -C -C
From: Aneesh Kumar K.V @ 2007-06-13 8:46 UTC (permalink / raw)
To: git; +Cc: gitster, Aneesh Kumar K.V
In-Reply-To: <142a3f15cd43680e0d7a02f09ffdd93864d13871.1181724308.git.aneesh.kumar@linux.vnet.ibm.com>
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
pass -C -C option to git-blame so that blame browsing
works when the data is copied over from other files.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 93ecfc1..5931766 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -533,7 +533,7 @@ class AnnotateWindow(object):
self.add_file_data(filename, commit_sha1, line_num)
- fp = os.popen("git blame --incremental -- " + filename + " " + commit_sha1)
+ fp = os.popen("git blame --incremental -C -C -- " + filename + " " + commit_sha1)
flags = fcntl.fcntl(fp.fileno(), fcntl.F_GETFL)
fcntl.fcntl(fp.fileno(), fcntl.F_SETFL, flags | os.O_NONBLOCK)
self.io_watch_tag = gobject.io_add_watch(fp, gobject.IO_IN, self.data_ready)
--
1.5.2.1.255.gca6c0-dirty
^ permalink raw reply related
* [PATCH 1/2] gitview: Fix the blame interface.
From: Aneesh Kumar K.V @ 2007-06-13 8:46 UTC (permalink / raw)
To: git; +Cc: gitster, Aneesh Kumar K.V
The async reading from the pipe was skipping some of the
input lines. Fix the same by making sure that we add the
partial content of the previous read to the newly read
data.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 098cb01..93ecfc1 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -352,6 +352,7 @@ class AnnotateWindow(object):
self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
self.window.set_border_width(0)
self.window.set_title("Git repository browser annotation window")
+ self.prev_read = ""
# Use two thirds of the screen by default
screen = self.window.get_screen()
@@ -401,7 +402,10 @@ class AnnotateWindow(object):
def data_ready(self, source, condition):
while (1):
try :
- buffer = source.read(8192)
+ # A simple readline doesn't work
+ # a readline bug ??
+ buffer = source.read(100)
+
except:
# resource temporary not available
return True
@@ -411,6 +415,19 @@ class AnnotateWindow(object):
source.close()
return False
+ if (self.prev_read != ""):
+ buffer = self.prev_read + buffer
+ self.prev_read = ""
+
+ if (buffer[len(buffer) -1] != '\n'):
+ try:
+ newline_index = buffer.rindex("\n")
+ except ValueError:
+ newline_index = 0
+
+ self.prev_read = buffer[newline_index:(len(buffer))]
+ buffer = buffer[0:newline_index]
+
for buff in buffer.split("\n"):
annotate_line = re.compile('^([0-9a-f]{40}) (.+) (.+) (.+)$')
m = annotate_line.match(buff)
--
1.5.2.1.255.gca6c0-dirty
^ permalink raw reply related
* Re: [PATCH 1/2] gitview: Fix the blame interface.
From: Aneesh Kumar @ 2007-06-13 8:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vmyz4h2nb.fsf@assigned-by-dhcp.pobox.com>
On 6/13/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@gmail.com> writes:
>
> > @@ -401,7 +402,11 @@ class AnnotateWindow(object):
> > def data_ready(self, source, condition):
> > while (1):
> > try :
> > - buffer = source.read(8192)
> > + # A simple readline doesn't work
> > + # a readline bug ??
> > + buffer=""
> > + buffer = source.read(100)
> > +
>
> Are you sure about the first assignment?
>
That was a debug left over i guess. I will send an update patch which
removed the same.
The problem was an interrupted source.read/readline was returning old values.
> > @@ -419,7 +432,8 @@ class AnnotateWindow(object):
> > m = annotate_line.match(buff)
> > if not m:
> > continue
> > - filename = m.group(2)
> > + else:
> > + filename = m.group(2)
> > else:
> > self.commit_sha1 = m.group(1)
> > self.source_line = int(m.group(2))
>
> The script is in contrib/ so I probably shouldn't be nitpicking,
> but for this particular hunk, I think (1) this is a no-op
> change, and (2) the original is easier to read.
>
>
I will update if you feel that way
-aneesh
^ permalink raw reply
* Re: [PATCH] Teach Makefile to respect external variables: CFLAGS and others.
From: Eygene Ryabinkin @ 2007-06-13 7:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sam, git
In-Reply-To: <7vhcpcfglr.fsf@assigned-by-dhcp.pobox.com>
Junio,
Wed, Jun 13, 2007 at 12:39:28AM -0700, Junio C Hamano wrote:
> > But anyway, this patch is only my suggestion, and it can be
> > thrown away :)
>
> Oh, I will, very gladly ;-), as it is obviously inferior than
> how we currently do our build.
OK, then this topic can be closed ;))
Thank you!
--
Eygene
^ permalink raw reply
* Re: [PATCH] Teach Makefile to respect external variables: CFLAGS and others.
From: Matthias Lederhofer @ 2007-06-13 7:42 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20070613071514.GP86872@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> wrote:
> Junio, Sam, good day.
>
> Tue, Jun 12, 2007 at 11:07:56PM -0700, Junio C Hamano wrote:
> > I run "make CFLAGS=-O0 -g" all the time. Also "make CC=echo"
> > seems to "work" as expected ;-).
> >
> > Care to elaborate what problem you are trying to solve?
>
> As Sam Ravnborg kindly pointed out, you're using make variables
> and I am trying to give the respect to the environment variables.
>
> And the real problem is that one (for example, me) can try to
> build Git with the different compiler than CC (gccX or icc, for
> example). And it is much better for lazy people to do 'export
> CC=whatever' once and then fire make any number of times ;))
>
> Answering Sam: yes, with my patch it is easier to inherit the
> variables from the environment. But it is not clear if it is
> good or bad ;))
>
> But anyway, this patch is only my suggestion, and it can be
> thrown away :)
If you want to fix it for your own checkout of git just put whatever
you like in config.mak. For example I add -ggdb3 to CFLAGS, set the
prefix variable and add some custom make targets in this file.
^ permalink raw reply
* Re: [PATCH] Edit user manual for grammar
From: Andy Parkins @ 2007-06-13 7:39 UTC (permalink / raw)
To: git; +Cc: David Kastrup
In-Reply-To: <86hcpcxr2v.fsf@lola.quinscape.zz>
On Wednesday 2007 June 13, David Kastrup wrote:
> Nope. It was used in "a last-resort method", namely in the
> adjectivized meaning. Without the hyphen, it would become the last of
> some resort methods, quite something different (and nonsensical).
Agreed. I withdraw my objection.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Teach Makefile to respect external variables: CFLAGS and others.
From: Junio C Hamano @ 2007-06-13 7:39 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: sam, git
In-Reply-To: <20070613071514.GP86872@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> writes:
> Junio, Sam, good day.
>
> Tue, Jun 12, 2007 at 11:07:56PM -0700, Junio C Hamano wrote:
>> I run "make CFLAGS=-O0 -g" all the time. Also "make CC=echo"
>> seems to "work" as expected ;-).
>>
>> Care to elaborate what problem you are trying to solve?
>
> As Sam Ravnborg kindly pointed out, you're using make variables
> and I am trying to give the respect to the environment variables.
>
> And the real problem is that one (for example, me) can try to
> build Git with the different compiler than CC (gccX or icc, for
> example). And it is much better for lazy people to do 'export
> CC=whatever' once and then fire make any number of times ;))
>
> Answering Sam: yes, with my patch it is easier to inherit the
> variables from the environment. But it is not clear if it is
> good or bad ;))
>
> But anyway, this patch is only my suggestion, and it can be
> thrown away :)
Oh, I will, very gladly ;-), as it is obviously inferior than
how we currently do our build.
I would personally hate environment affecting build (or anything
for that matter), as it makes it unnecessarily difficult to
diagnose when something goes wrong. I consider that it is a
beautiful thing that make can take explicit override from the
command line.
Lazy people like me can always have a make wrapper. E.g. I have
a checkout of my 'todo' branch at Meta in git.git repository, so
I would say
$ Meta/Make -pedantic
to ask for specific set of CFLAGS. If something goes wrong and
I need to ask for help from other people, it is crystal clear to
them that I am using something "customized" from the above
command line.
If you modify Makefile to allow the build procedure to be easily
contaminated with stray environment, and when your build breaks,
you would answer that your command line is:
$ make
when asked how you tried to build things -- and leave people who
try to help you scratching their head, wasting their time.
^ permalink raw reply
* Re: [PATCH] Edit user manual for grammar
From: David Kastrup @ 2007-06-13 7:17 UTC (permalink / raw)
To: git
In-Reply-To: <200706122028.01310.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> "last-resort" doesn't need to be compound because separated it still
> means "the resort that is last".
The context was "a last-resort method". In this case, I consider the
hyphen necessary in order to keep the adjectivization connected.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Edit user manual for grammar
From: David Kastrup @ 2007-06-13 7:15 UTC (permalink / raw)
To: git
In-Reply-To: <20070612175421.GA26767@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Tue, Jun 12, 2007 at 04:43:19PM +0100, Andy Parkins wrote:
>> - "last-resort" is two words, not a conjoined word, it doesn't require
>> the hyphen
>
> Right, but when you've got a couple words functioning together to modify
> a following noun, the hyphen's pretty standard: "rosy-fingered
> dawn".
This rendition of ῥοδοδάκτυλος Ἠώς is an adjectivized verb construct,
like well-hung, good-natured, forward-looking, thinly-veiled (the
latter can be written as two words, too, however).
> Is this case an exception? I suspect it's fine either way....
Nope. It was used in "a last-resort method", namely in the
adjectivized meaning. Without the hyphen, it would become the last of
some resort methods, quite something different (and nonsensical).
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Teach Makefile to respect external variables: CFLAGS and others.
From: Eygene Ryabinkin @ 2007-06-13 7:15 UTC (permalink / raw)
To: Junio C Hamano, sam; +Cc: git
In-Reply-To: <7v4plcgzer.fsf@assigned-by-dhcp.pobox.com>
Junio, Sam, good day.
Tue, Jun 12, 2007 at 11:07:56PM -0700, Junio C Hamano wrote:
> I run "make CFLAGS=-O0 -g" all the time. Also "make CC=echo"
> seems to "work" as expected ;-).
>
> Care to elaborate what problem you are trying to solve?
As Sam Ravnborg kindly pointed out, you're using make variables
and I am trying to give the respect to the environment variables.
And the real problem is that one (for example, me) can try to
build Git with the different compiler than CC (gccX or icc, for
example). And it is much better for lazy people to do 'export
CC=whatever' once and then fire make any number of times ;))
Answering Sam: yes, with my patch it is easier to inherit the
variables from the environment. But it is not clear if it is
good or bad ;))
But anyway, this patch is only my suggestion, and it can be
thrown away :)
--
Eygene
^ permalink raw reply
* Re: [PATCH] Add a local implementation of hstrerror for the system which do not have it
From: Johannes Sixt @ 2007-06-13 7:05 UTC (permalink / raw)
To: git
In-Reply-To: <20070612213129.GD2459@steel.home>
Alex Riesen wrote:
> + static char buffer[32];
> ...
> + sprintf(buffer, "Name resolution error %d", err);
I don't think it's a problem for any current implementation, but it
would be better to err on the conservative side: The buffer should be at
least 44 chars wide to account for 20 digit negative numbers (thats the
maximum if int is 64 bits wide).
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: subdirectory filter needs --full-history
From: Junio C Hamano @ 2007-06-13 6:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <alpine.LFD.0.98.0706081822500.4205@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> ... There was no actual developmet on branch
> "another", so all the commits went away, but it left the merge (because
> that's how --full-history works), which has now become pointless.
>
> So you should do a "merge cleanup" phase after running --full-history.
In short, you will end up with something like this:
.---. (side branch)
/ \
---A---B---C (merge)
The "merge clean-up" would conceptually be a simple operation.
Whenever you see a merge C, you look at its parents A and B, and
cull the ones that are reachable from other parents. You notice
that A is an ancestor of B, drop A from the parents of C, and
simplify the above down to:
---A---B---C (not-a-merge)
However, I suspect that this is impossible without making
--full-history with "merge clean-up" imply "limited".
In the case of filter-branch, it needs to use topo-order in
order to guarantee that all its parents commits have been
rewritten before rewriting a commit, so the traversal is already
limited.
It might be simpler for filter-branch to remove parents that are
ancestor of other parents ("git show-branch --independent" would
work well for this, I think), before feeding the list of mapped
parents to the parent-filter.
^ permalink raw reply
* Re: [PATCH] Teach Makefile to respect external variables: CFLAGS and others.
From: Sam Ravnborg @ 2007-06-13 6:12 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20070613054229.GM86872@void.codelabs.ru>
On Wed, Jun 13, 2007 at 09:42:30AM +0400, Eygene Ryabinkin wrote:
> If one is not using the configure script, then there is no way to
> redefine variables CFLAGS, LFLAGS, CC, AR, TAR, INSTALL, RPMBUILD,
> TCL_PATCH and TCLTK_PATH. This shouldn't be so, since these variables
> can be manually set by user and we should respect them.
make distingush between environment variables and make variables.
So for make there is a big difference between:
export FOO=foobar
make
and
make FOO=foobar
The latter will work as expected without your changes.
And the good part about this is that some random environment variables
does not influence the build.
Sam
^ permalink raw reply
* Re: [PATCH] Teach Makefile to respect external variables: CFLAGS and others.
From: Junio C Hamano @ 2007-06-13 6:07 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20070613054229.GM86872@void.codelabs.ru>
I run "make CFLAGS=-O0 -g" all the time. Also "make CC=echo"
seems to "work" as expected ;-).
Care to elaborate what problem you are trying to solve?
^ permalink raw reply
* [PATCH] Teach Makefile to respect external variables: CFLAGS and others.
From: Eygene Ryabinkin @ 2007-06-13 5:42 UTC (permalink / raw)
To: git
If one is not using the configure script, then there is no way to
redefine variables CFLAGS, LFLAGS, CC, AR, TAR, INSTALL, RPMBUILD,
TCL_PATCH and TCLTK_PATH. This shouldn't be so, since these variables
can be manually set by user and we should respect them.
The patch originates from the FreeBSD port and was originally made
by Ed Schouten, ed at fxq dot nl.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
---
Makefile | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Makefile b/Makefile
index 30a4052..6cd9ea2 100644
--- a/Makefile
+++ b/Makefile
@@ -135,8 +135,8 @@ uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
# CFLAGS and LDFLAGS are for the users to override from the command line.
-CFLAGS = -g -O2 -Wall
-LDFLAGS =
+CFLAGS ?= -g -O2 -Wall
+LDFLAGS ?=
ALL_CFLAGS = $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
@@ -172,13 +172,13 @@ GITWEB_SITE_FOOTER =
export prefix bindir gitexecdir sharedir template_dir sysconfdir
-CC = gcc
-AR = ar
-TAR = tar
-INSTALL = install
-RPMBUILD = rpmbuild
-TCL_PATH = tclsh
-TCLTK_PATH = wish
+CC ?= gcc
+AR ?= ar
+TAR ?= tar
+INSTALL ?= install
+RPMBUILD ?= rpmbuild
+TCL_PATH ?= tclsh
+TCLTK_PATH ?= wish
export TCL_PATH TCLTK_PATH
--
1.5.2.1
^ permalink raw reply related
* [PATCH] Introduce file with the common default build-time items.
From: Eygene Ryabinkin @ 2007-06-13 5:43 UTC (permalink / raw)
To: git
Words 'wish' and 'tclsh' are scattered across at least three files,
but they are tied to the same entities. To ease the maintenance
and remove errors, these configuration items were gathered into the
separate file named 'common-make-vars.def'.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
---
Makefile | 17 +++++++++++------
common-make-vars.def | 11 +++++++++++
configure.ac | 4 +++-
git-gui/Makefile | 6 ++++--
4 files changed, 29 insertions(+), 9 deletions(-)
create mode 100644 common-make-vars.def
diff --git a/Makefile b/Makefile
index 6cd9ea2..e98f16b 100644
--- a/Makefile
+++ b/Makefile
@@ -116,16 +116,21 @@ all::
#
# The TCL_PATH variable governs the location of the Tcl interpreter
# used to optimize git-gui for your system. Only used if NO_TCLTK
-# is not set. Defaults to the bare 'tclsh'.
+# is not set. Defaults to the value of the __GIT_DEFAULT_TCLSH_NAME
+# from common-make-vars.def.
#
-# The TCLTK_PATH variable governs the location of the Tcl/Tk interpreter.
-# If not set it defaults to the bare 'wish'. If it is set to the empty
-# string then NO_TCLTK will be forced (this is used by configure script).
+# The TCLTK_PATH variable governs the location of the Tcl/Tk
+# interpreter. If not set it defaults to the value of the
+# __GIT_DEFAULT_TCLTK_NAME from common-make-vars.def. If it is set
+# to the empty string then NO_TCLTK will be forced (this is used
+# by configure script).
#
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
+# Default values
+-include common-make-vars.def
uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
@@ -177,8 +182,8 @@ AR ?= ar
TAR ?= tar
INSTALL ?= install
RPMBUILD ?= rpmbuild
-TCL_PATH ?= tclsh
-TCLTK_PATH ?= wish
+TCL_PATH ?= $(__GIT_DEFAULT_TCLSH_NAME)
+TCLTK_PATH ?= $(__GIT_DEFAULT_TCLTK_NAME)
export TCL_PATH TCLTK_PATH
diff --git a/common-make-vars.def b/common-make-vars.def
new file mode 100644
index 0000000..43a3a8b
--- /dev/null
+++ b/common-make-vars.def
@@ -0,0 +1,11 @@
+# This file is meant to be sourced from the autoconf script
+# and included from the Makefile. It carries the default values
+# to eliminate their redundancy across the files. The syntax
+# is 'name=value' without extra spaces across the '=' sign to
+# make shell happy. Symbols '#' are starting comments ;))
+
+# Default Tcl/Tk interpreter name
+__GIT_DEFAULT_TCLTK_NAME=wish
+
+# Default Tcl interpreter name
+__GIT_DEFAULT_TCLSH_NAME=tclsh
diff --git a/configure.ac b/configure.ac
index 50d2b85..fd1d241 100644
--- a/configure.ac
+++ b/configure.ac
@@ -12,6 +12,8 @@ config_in=config.mak.in
echo "# ${config_append}. Generated by configure." > "${config_append}"
+## Defaults
+source common-make-vars.def
## Definitions of macros
# GIT_CONF_APPEND_LINE(LINE)
@@ -97,7 +99,7 @@ AC_CHECK_PROGS(TAR, [gtar tar])
if test -z "$NO_TCLTK"; then
if test "$with_tcltk" = ""; then
# No Tcl/Tk switches given. Do not check for Tcl/Tk, use bare 'wish'.
- TCLTK_PATH=wish
+ TCLTK_PATH=${__GIT_DEFAULT_TCLTK_NAME}
AC_SUBST(TCLTK_PATH)
elif test "$with_tcltk" = "yes"; then
# Tcl/Tk check requested.
diff --git a/git-gui/Makefile b/git-gui/Makefile
index 3de0de1..654641a 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -6,6 +6,8 @@ all::
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
+# Default values
+-include ../common-make-vars.def
SCRIPT_SH = git-gui.sh
GITGUI_BUILT_INS = git-citool
@@ -36,8 +38,8 @@ ifndef V
QUIET_2DEVNULL = 2>/dev/null
endif
-TCL_PATH ?= tclsh
-TCLTK_PATH ?= wish
+TCL_PATH ?= $(__GIT_DEFAULT_TCLSH_NAME)
+TCLTK_PATH ?= $(__GIT_DEFAULT_TCLTK_NAME}
ifeq ($(findstring $(MAKEFLAGS),s),s)
QUIET_GEN =
--
1.5.2.1
^ permalink raw reply related
* [PATCH] Add --with-tclsh argument to configure script.
From: Eygene Ryabinkin @ 2007-06-13 5:44 UTC (permalink / raw)
To: git
We have Tcl/Tk interpreter detection, so we should have Tcl interpreter
detection. It is used just at the build time now, but it produces
the index that speeds up the git-gui loading.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
---
config.mak.in | 1 +
configure.ac | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index a3032e3..7601881 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -7,6 +7,7 @@ AR = @AR@
TAR = @TAR@
#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
TCLTK_PATH = @TCLTK_PATH@
+TCL_PATH = @TCLSH_PATH@
prefix = @prefix@
exec_prefix = @exec_prefix@
diff --git a/configure.ac b/configure.ac
index fd1d241..184a466 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,6 +85,16 @@ AS_HELP_STRING([],[Bare --with-tcltk will make the GUI part only if])
AS_HELP_STRING([],[Tcl/Tk interpreter will be found in a system.]),\
GIT_PARSE_WITH(tcltk))
#
+# Declare the with-tclsh/without-tclsh options.
+AC_ARG_WITH(tclsh,
+AS_HELP_STRING([--with-tclsh],[Tcl interpreter path])
+AS_HELP_STRING([],[ARG is the full path to the Tcl interpreter that])
+AS_HELP_STRING([],[is needed only during the compilation time.])
+AS_HELP_STRING([],[Bare --with-tclsh will search for the Tcl])
+AS_HELP_STRING([],[interpreter and use it. If no interpreter])
+AS_HELP_STRING([],[will be found, then the default one will be used]),\
+GIT_PARSE_WITH(tclsh))
+#
## Checks for programs.
@@ -110,6 +120,30 @@ if test -z "$NO_TCLTK"; then
AC_SUBST(TCLTK_PATH)
fi
fi
+# TCLSH_PATH will be set to the name of the Tcl interpreter.
+# Possibly the name will be the fully qualified path, but
+# it can be just the interpreter name. TCLSH_PATH will be
+# empty only in one case: when NO_TCLTK is defined.
+if test -z "$NO_TCLTK"; then
+ if test "$with_tclsh" = ""; then
+ # No Tcl interpreter switches given.
+ # Do not check for Tcl interpreter, use bare 'tclsh'.
+ TCLSH_PATH=${__GIT_DEFAULT_TCLSH_NAME}
+ AC_SUBST(TCLSH_PATH)
+ elif test "$with_tclsh" = "yes"; then
+ # Tcl interpreter check requested.
+ AC_CHECK_PROGS(TCLSH_PATH, [tclsh], )
+ if test -z "$TCLSH_PATH"; then
+ AC_MSG_RESULT([Tcl interpreter was not found in the PATH. Using bare '${__GIT_DEFAULT_TCLSH_NAME}'])
+ TCLSH_PATH=${__GIT_DEFAULT_TCLSH_NAME}
+ AC_SUBST(TCLSH_PATH)
+ fi
+ else
+ AC_MSG_RESULT([Using Tcl interpreter $with_tclsh])
+ TCLSH_PATH="$with_tclsh"
+ AC_SUBST(TCLSH_PATH)
+ fi
+fi
## Checks for libraries.
AC_MSG_NOTICE([CHECKS for libraries])
--
1.5.2.1
^ permalink raw reply related
* Re: [PATCH] make git barf when an alias changes environment variables
From: Matthias Lederhofer @ 2007-06-13 5:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejkgh1jf.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> What does this patch do when you do this?
>
> : Because I usually work with this repository...
> $ GIT_DIR=$some_repository
> $ export GIT_DIR
>
> : Then much later, I happen to visit another repository
> : to take a peek...
> $ cd $somewhere_else
> $ git --git-dir .git some-command
>
This one has no alias involved as far as I see, so there is no change.
The patch makes git barf when an alias changes the environment (i.e.
an alias uses --git-dir/--work-tree/--bare). When git has read the
configuration file to find out about aliases setup_git_env has been
called and a pointer returned by getenv("GIT_DIR") is already stored
in a static pointer. If the environment variable is changed
afterwards git might or might not use the new value depending on the
implementation.
That is what my example shows: FreeBSD libc reuses the old memory
location if the new value of an environment variable fits in the old
place. Because setup_git_env uses xstrdup on the object dir and some
other directories the old value is used for those but the new one is
used for git_dir (which is just a pointer returned by getenv). This
way HEAD is read from the new repository but objects are searched in
the old repository.
^ permalink raw reply
* Re: [PATCH] make git barf when an alias changes environment variables
From: Junio C Hamano @ 2007-06-13 5:21 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070608205755.GA21901@moooo.ath.cx>
What does this patch do when you do this?
: Because I usually work with this repository...
$ GIT_DIR=$some_repository
$ export GIT_DIR
: Then much later, I happen to visit another repository
: to take a peek...
$ cd $somewhere_else
$ git --git-dir .git some-command
I think --git-dir request on the command line is primarily to
allow overriding whatever the user has in the environment as the
fallback default, so if the patch makes it barf that is not very
nice.
^ permalink raw reply
* Re: [PATCH 2/2] gitview: run blame with -M and -C
From: Junio C Hamano @ 2007-06-13 4:59 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git
In-Reply-To: <1181669728642-git-send-email-aneesh.kumar@gmail.com>
"Aneesh Kumar K.V" <aneesh.kumar@gmail.com> writes:
> From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
>
> pass -M and -C option to git-blame so that blame browsing
> works when the data is copied over from other files.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
> ---
> contrib/gitview/gitview | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
> index 286e974..01128f4 100755
> --- a/contrib/gitview/gitview
> +++ b/contrib/gitview/gitview
> @@ -530,7 +530,7 @@ class AnnotateWindow(object):
>
> self.add_file_data(filename, commit_sha1, line_num)
>
> - fp = os.popen("git blame --incremental -- " + filename + " " + commit_sha1)
> + fp = os.popen("git blame --incremental -M -C -C -- " + filename + " " + commit_sha1)
You do not have to say "-M -C -C"; "-C" would imply "-M"
anyway.
^ permalink raw reply
* Re: [PATCH 1/2] gitview: Fix the blame interface.
From: Junio C Hamano @ 2007-06-13 4:58 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git
In-Reply-To: <11816697213806-git-send-email-aneesh.kumar@gmail.com>
"Aneesh Kumar K.V" <aneesh.kumar@gmail.com> writes:
> @@ -401,7 +402,11 @@ class AnnotateWindow(object):
> def data_ready(self, source, condition):
> while (1):
> try :
> - buffer = source.read(8192)
> + # A simple readline doesn't work
> + # a readline bug ??
> + buffer=""
> + buffer = source.read(100)
> +
Are you sure about the first assignment?
> @@ -419,7 +432,8 @@ class AnnotateWindow(object):
> m = annotate_line.match(buff)
> if not m:
> continue
> - filename = m.group(2)
> + else:
> + filename = m.group(2)
> else:
> self.commit_sha1 = m.group(1)
> self.source_line = int(m.group(2))
The script is in contrib/ so I probably shouldn't be nitpicking,
but for this particular hunk, I think (1) this is a no-op
change, and (2) the original is easier to read.
^ permalink raw reply
* Re: [PATCH] Interpret :/<pattern> as a regular expression
From: Junio C Hamano @ 2007-06-13 4:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706130148080.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/sha1_name.c b/sha1_name.c
> index d9188ed..f1ba194 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -611,6 +611,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> {
> struct commit_list *list = NULL, *backup = NULL, *l;
> int retval = -1;
> + regex_t regexp;
> + regmatch_t regmatch[1];
>
> if (prefix[0] == '!') {
> if (prefix[1] != '!')
Because you are not extracting any match substring, I do not
think you would need regmatch[] there.
> @@ -622,6 +624,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> for_each_ref(handle_one_ref, &list);
> for (l = list; l; l = l->next)
> commit_list_insert(l->item, &backup);
> + if (regcomp(®exp, prefix, REG_EXTENDED))
> + return error("invalid regexp: %s", prefix);
> while (list) {
> char *p;
> struct commit *commit;
Why EXTENDED?
I think our code prefer traditional regexp by default, but in
places where extended behaviour is truly useful (e.g. grepping
for bulk of text) have command line option to enable extended.
Of course, extended SHA-1 notation has no chance to do "command
line option", but it somehow feels inconsistent.
Also you probably want REG_NEWLINE.
> @@ -630,7 +634,9 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> parse_object(commit->object.sha1);
> if (!commit->buffer || !(p = strstr(commit->buffer, "\n\n")))
> continue;
> - if (!prefixcmp(p + 2, prefix)) {
> + if (!regexec(®exp, p + 2, 1, regmatch, 0) &&
> + printf("match: %d\n", regmatch[0].rm_so) &&
> + regmatch[0].rm_so == 0) {
> hashcpy(sha1, commit->object.sha1);
> retval = 0;
> break;
Do we want to detect return value other than REG_NOMATCH from
regexec() when it does not return zero?
Please lose the debugging printf() before submitting.
> @@ -639,6 +645,7 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> free_commit_list(list);
> for (l = backup; l; l = l->next)
> clear_commit_marks(l->item, ONELINE_SEEN);
> + regfree(®exp);
> return retval;
> }
>
Also I think you would want to fix get_sha1_oneline() so that it
not to refuse to work without save_commit_buffer. These are to
parse user supplied strings (it would be crazy for scripts to
throw hundreds of ':/random string' to drive git -- it must come
from the end user), and the user has every right to use this
syntax, if he wants to, to specify the starting point for a
command that deliberately turns off save_commit_buffer to save
memory, because the command knows ithat t will traverse tons of
commits without needing the contents of the commit buffer.
After parse_object(), if commit->buffer is NULL, read the buffer
with read_sha1_file() yourself to look for match (and if you did
so you are also responsible for discarding it yourself).
^ permalink raw reply
* Re: [PATCH] Interpret :/<pattern> as a regular expression
From: Junio C Hamano @ 2007-06-13 1:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706130148080.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Earlier, Git interpreted the pattern as a strict prefix, which made
> the operator unsuited in many cases.
>
> Now, the pattern is interpreted as a regular expression (which does not
> change the behaviour too much, since few onelines contain special regex
> characters), so that you can say
>
> git diff :/.*^Signed-off-by:.Zack.Brown
>
> to see the diff against the most recent reachable commit which was
> signed off by Zack, whose Kernel Cousin I miss very much.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
While this perhaps is an improvement and people who are not
interested in paying the price have a choice of not using this
silly syntax, I am moderately annoyed that the syntax does not
define "the most recent reachable" very well. It is more like
"the first one we happened to pick by diffing from reachable
refs". It would be more useful if it took "$commit:/$pattern"
form to limit the search among reachable ones from named commit.
^ permalink raw reply
* [PATCH] Interpret :/<pattern> as a regular expression
From: Johannes Schindelin @ 2007-06-13 0:50 UTC (permalink / raw)
To: git
Earlier, Git interpreted the pattern as a strict prefix, which made
the operator unsuited in many cases.
Now, the pattern is interpreted as a regular expression (which does not
change the behaviour too much, since few onelines contain special regex
characters), so that you can say
git diff :/.*^Signed-off-by:.Zack.Brown
to see the diff against the most recent reachable commit which was
signed off by Zack, whose Kernel Cousin I miss very much.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
For fun, you can see which committer signed himself off:
git show :/.*^Signed-off:
*grin*
sha1_name.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index d9188ed..f1ba194 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -611,6 +611,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
{
struct commit_list *list = NULL, *backup = NULL, *l;
int retval = -1;
+ regex_t regexp;
+ regmatch_t regmatch[1];
if (prefix[0] == '!') {
if (prefix[1] != '!')
@@ -622,6 +624,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
for_each_ref(handle_one_ref, &list);
for (l = list; l; l = l->next)
commit_list_insert(l->item, &backup);
+ if (regcomp(®exp, prefix, REG_EXTENDED))
+ return error("invalid regexp: %s", prefix);
while (list) {
char *p;
struct commit *commit;
@@ -630,7 +634,9 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
parse_object(commit->object.sha1);
if (!commit->buffer || !(p = strstr(commit->buffer, "\n\n")))
continue;
- if (!prefixcmp(p + 2, prefix)) {
+ if (!regexec(®exp, p + 2, 1, regmatch, 0) &&
+ printf("match: %d\n", regmatch[0].rm_so) &&
+ regmatch[0].rm_so == 0) {
hashcpy(sha1, commit->object.sha1);
retval = 0;
break;
@@ -639,6 +645,7 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
free_commit_list(list);
for (l = backup; l; l = l->next)
clear_commit_marks(l->item, ONELINE_SEEN);
+ regfree(®exp);
return retval;
}
--
1.5.2.1.2827.gba84a8-dirty
^ permalink raw reply related
* Re: git-fetch, was Re: [PATCH] Port git-tag.sh to C.
From: Johannes Schindelin @ 2007-06-13 0:27 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Julian Phillips, Carlos Rica, =?X-UNKNOWN?Q?Kristian_H=F8gsberg?=,
git
In-Reply-To: <Pine.LNX.4.64.0706121953080.5848@iabervon.org>
Hi,
On Tue, 12 Jun 2007, Daniel Barkalow wrote:
> Okay, git://iabervon.org/~barkalow/git.git builtin-fetch.
Thanks!
Ciao,
Dscho
^ permalink raw reply
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