* [PATCH] Fix errno usage in connect.c
From: Petr Baudis @ 2006-07-01 21:56 UTC (permalink / raw)
To: Morten Welinder; +Cc: GIT Mailing List
In-Reply-To: <118833cc0606280956s4081029ci5b3cd1fdf4b10c97@mail.gmail.com>
Dear diary, on Wed, Jun 28, 2006 at 06:56:12PM CEST, I got a letter
where Morten Welinder <mwelinder@gmail.com> said that...
> It looks like connect.c waits too long before it uses errno in both copies
> of git_tcp_connect_sock. Both close and freeaddrinfo can poke any
> non-zero value in there.
Nice catch.
->8-
errno was used after it could've been modified by a subsequent library call.
Spotted by Morten Welinder.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
connect.c | 18 ++++++++++++------
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/connect.c b/connect.c
index cb4656d..9a87bd9 100644
--- a/connect.c
+++ b/connect.c
@@ -328,7 +328,7 @@ #ifndef NO_IPV6
*/
static int git_tcp_connect_sock(char *host)
{
- int sockfd = -1;
+ int sockfd = -1, saved_errno = 0;
char *colon, *end;
const char *port = STR(DEFAULT_GIT_PORT);
struct addrinfo hints, *ai0, *ai;
@@ -362,9 +362,12 @@ static int git_tcp_connect_sock(char *ho
for (ai0 = ai; ai; ai = ai->ai_next) {
sockfd = socket(ai->ai_family,
ai->ai_socktype, ai->ai_protocol);
- if (sockfd < 0)
+ if (sockfd < 0) {
+ saved_errno = errno;
continue;
+ }
if (connect(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
+ saved_errno = errno;
close(sockfd);
sockfd = -1;
continue;
@@ -375,7 +378,7 @@ static int git_tcp_connect_sock(char *ho
freeaddrinfo(ai0);
if (sockfd < 0)
- die("unable to connect a socket (%s)", strerror(errno));
+ die("unable to connect a socket (%s)", strerror(saved_errno));
return sockfd;
}
@@ -387,7 +390,7 @@ #else /* NO_IPV6 */
*/
static int git_tcp_connect_sock(char *host)
{
- int sockfd = -1;
+ int sockfd = -1, saved_errno = 0;
char *colon, *end;
char *port = STR(DEFAULT_GIT_PORT), *ep;
struct hostent *he;
@@ -426,8 +429,10 @@ static int git_tcp_connect_sock(char *ho
for (ap = he->h_addr_list; *ap; ap++) {
sockfd = socket(he->h_addrtype, SOCK_STREAM, 0);
- if (sockfd < 0)
+ if (sockfd < 0) {
+ saved_errno = errno;
continue;
+ }
memset(&sa, 0, sizeof sa);
sa.sin_family = he->h_addrtype;
@@ -435,6 +440,7 @@ static int git_tcp_connect_sock(char *ho
memcpy(&sa.sin_addr, *ap, he->h_length);
if (connect(sockfd, (struct sockaddr *)&sa, sizeof sa) < 0) {
+ saved_errno = errno;
close(sockfd);
sockfd = -1;
continue;
@@ -443,7 +449,7 @@ static int git_tcp_connect_sock(char *ho
}
if (sockfd < 0)
- die("unable to connect a socket (%s)", strerror(errno));
+ die("unable to connect a socket (%s)", strerror(saved_errno));
return sockfd;
}
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply related
* Re: [PATCH] autoconf: Use autoconf to write installation directories to config.mak
From: Jakub Narebski @ 2006-07-01 22:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060701213305.GA29115@pasky.or.cz>
On 7/1/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Thu, Jun 29, 2006 at 08:23:31PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> It would have been a bit easier to swallow if this whole
>> machinery to build config.mk were somewhere under contrib/ (say
>> in contrib/autoconf), with an instruction to make an "opt-in"
>> symlink "ln -s contrib/autoconf/config.mk config.mk" for people
>> who want to use it in the toplevel INSTALL file, perhaps.
>
> Well, I don't get the point of that - it doesn't make any sense to me to
> require this.
>
> The point of ./configure is to make things easier for the user, so to
> balance that we should make the ./configure harder to _call_ by requiring
> the user to do strange arbitrary steps after calling it.
Easiest way is to output ./configure result to e.g. configure.mak.autoconf,
and include this file just before configure.mak in main Makefile.
Just as in patches (although you have to discard or revert two alternate
mechanism patches)
--
Jakub Narebski
^ permalink raw reply
* [PATCH/RFC (updated)] Add git-instaweb, instantly browse the working repo with gitweb
From: Eric Wong @ 2006-07-01 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtayh56z.fsf@assigned-by-dhcp.cox.net>
I got tired of having to configure gitweb for every repository
I work on. I sometimes prefer gitweb to standard GUIs like gitk
or gitview; so this lets me automatically configure gitweb to
browse my working repository and also opens my browser to it.
Updates from the original patch:
Added Apache/mod_perl2 compatibility if Dennis Stosberg's gitweb
has been applied, too: <20060621130708.Gcbc6e5c@leonov.stosberg.net>
General cleanups in shell code usage.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > I got tired of having to configure gitweb for every repository
> > I work on. I sometimes prefer gitweb to standard GUIs like gitk
> > or gitview; so this lets me automatically configure gitweb to
> > browse my working repository and also opens my browser to it.
> >
> > Signed-off-by: Eric Wong <normalperson@yhbt.net>
>
> This is cute but I haven't seen much responses to it yet. Are
> people uninterested?
I've found it very useful myself, but I wouldn't have made it if I
didn't :) It's somewhat of a strange and alien concept in GUIs, and
will probably take some getting used to; but I think it can gain users
quickly because it doesn't rely on any specific toolkits, and can be
expanded to support more HTTP servers.
If anything, it can also serve as short and simple documentation for
setting up gitweb.
.gitignore | 1
Documentation/git-instaweb.txt | 84 ++++++++++++++
Makefile | 16 +++
git-instaweb.sh | 235 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 335 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 7b954d5..2bcc604 100644
--- a/.gitignore
+++ b/.gitignore
@@ -46,6 +46,7 @@ git-http-push
git-imap-send
git-index-pack
git-init-db
+git-instaweb
git-local-fetch
git-log
git-lost-found
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
new file mode 100644
index 0000000..7dd393b
--- /dev/null
+++ b/Documentation/git-instaweb.txt
@@ -0,0 +1,84 @@
+git-instaweb(1)
+===============
+
+NAME
+----
+git-instaweb - instantly browse your working repository in gitweb
+
+SYNOPSIS
+--------
+'git-instaweb' [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
+
+'git-instaweb' [--start] [--stop] [--restart]
+
+DESCRIPTION
+-----------
+A simple script to setup gitweb and a web server for browsing the local
+repository.
+
+OPTIONS
+-------
+
+-l|--local::
+ Only bind the web server to the local IP (127.0.0.1).
+
+-d|--httpd::
+ The HTTP daemon command-line that will be executed.
+ Command-line options may be specified here, and the
+ configuration file will be added at the end of the command-line.
+ Currently, lighttpd and apache2 are the only supported servers.
+ (Default: lighttpd)
+
+-m|--module-path::
+ The module path (only needed if httpd is Apache).
+ (Default: /usr/lib/apache2/modules)
+
+-p|--port::
+ The port number to bind the httpd to. (Default: 1234)
+
+-b|--browser::
+
+ The web browser command-line to execute to view the gitweb page.
+ If blank, the URL of the gitweb instance will be printed to
+ stdout. (Default: 'firefox')
+
+--start::
+ Start the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance.
+
+--stop::
+ Stop the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance,
+ nor does it close the browser.
+
+--restart::
+ Restart the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance.
+
+CONFIGURATION
+-------------
+
+You may specify configuration in your .git/config
+
+-----------------------------------------------------------------------
+[instaweb]
+ local = true
+ httpd = apache2 -f
+ port = 4321
+ browser = konqueror
+ modulepath = /usr/lib/apache2/modules
+
+-----------------------------------------------------------------------
+
+Author
+------
+Written by Eric Wong <normalperson@yhbt.net>
+
+Documentation
+--------------
+Documentation by Eric Wong <normalperson@yhbt.net>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index cde619c..83d8922 100644
--- a/Makefile
+++ b/Makefile
@@ -142,7 +142,7 @@ SCRIPT_PYTHON = \
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
- git-cherry-pick git-status
+ git-cherry-pick git-status git-instaweb
# The ones that do not have to link with lcrypto, lz nor xdiff.
SIMPLE_PROGRAMS = \
@@ -545,6 +545,20 @@ git-status: git-commit
cp $< $@+
mv $@+ $@
+git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
+ rm -f $@ $@+
+ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
+ $@.sh | sed \
+ -e 's|@@GITWEB_CGI@@|#!$(PERL_PATH_SQ)|; T; r gitweb/gitweb.cgi' \
+ | sed \
+ -e 's|@@GITWEB_CSS@@||; T; r gitweb/gitweb.css' \
+ > $@+
+ chmod +x $@+
+ mv $@+ $@
+
# These can record GIT_VERSION
git$X git.spec \
$(patsubst %.sh,%,$(SCRIPT_SH)) \
diff --git a/git-instaweb.sh b/git-instaweb.sh
new file mode 100755
index 0000000..51067d9
--- /dev/null
+++ b/git-instaweb.sh
@@ -0,0 +1,235 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Eric Wong
+#
+USAGE='[--start] [--stop] [--restart]
+ [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
+ [--module-path=<path> (for Apache2 only)]'
+
+. git-sh-setup
+
+case "$GIT_DIR" in
+/*)
+ fqgitdir="$GIT_DIR" ;;
+*)
+ fqgitdir="$PWD/$GIT_DIR" ;;
+esac
+
+local="`git repo-config --bool --get instaweb.local`"
+httpd="`git repo-config --get instaweb.httpd`"
+browser="`git repo-config --get instaweb.browser`"
+port=`git repo-config --get instaweb.port`
+module_path="`git repo-config --get instaweb.modulepath`"
+
+conf=$GIT_DIR/gitweb/httpd.conf
+
+# Defaults:
+
+# if installed, it doens't need further configuration (module_path)
+test -z "$httpd" && httpd='lighttpd -f'
+
+# probably the most popular browser among gitweb users
+test -z "$browser" && browser='firefox'
+
+# any untaken local port will do...
+test -z "$port" && port=1234
+
+start_httpd () {
+ httpd_only="`echo $httpd | cut -f1 -d' '`"
+ if test "`expr index $httpd_only /`" -eq '1' || \
+ which $httpd_only >/dev/null
+ then
+ $httpd $fqgitdir/gitweb/httpd.conf
+ else
+ # many httpds are installed in /usr/sbin or /usr/local/sbin
+ # these days and those are not in most users $PATHs
+ for i in /usr/local/sbin /usr/sbin
+ do
+ if test -x "$i/$httpd_only"
+ then
+ # don't quote $httpd, there can be
+ # arguments to it (-f)
+ $i/$httpd "$fqgitdir/gitweb/httpd.conf"
+ return
+ fi
+ done
+ fi
+}
+
+stop_httpd () {
+ test -f "$fqgitdir/pid" && kill `cat "$fqgitdir/pid"`
+}
+
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ --stop|stop)
+ stop_httpd
+ exit 0
+ ;;
+ --start|start)
+ start_httpd
+ exit 0
+ ;;
+ --restart|restart)
+ stop_httpd
+ start_httpd
+ exit 0
+ ;;
+ --local|-l)
+ local=true
+ ;;
+ -d|--httpd|--httpd=*)
+ case "$#,$1" in
+ *,*=*)
+ httpd=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ httpd="$2"
+ shift ;;
+ esac
+ ;;
+ -b|--browser|--browser=*)
+ case "$#,$1" in
+ *,*=*)
+ browser=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ browser="$2"
+ shift ;;
+ esac
+ ;;
+ -p|--port|--port=*)
+ case "$#,$1" in
+ *,*=*)
+ port=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ port="$2"
+ shift ;;
+ esac
+ ;;
+ -m|--module-path=*|--module-path)
+ case "$#,$1" in
+ *,*=*)
+ module_path=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ module_path="$2"
+ shift ;;
+ esac
+ ;;
+ *)
+ usage
+ ;;
+ esac
+ shift
+done
+
+mkdir -p "$GIT_DIR/gitweb/tmp"
+GIT_EXEC_PATH="`git --exec-path`"
+GIT_DIR="$fqgitdir"
+export GIT_EXEC_PATH GIT_DIR
+
+
+lighttpd_conf () {
+ cat > "$conf" <<EOF
+server.document-root = "$fqgitdir/gitweb"
+server.port = $port
+server.modules = ( "mod_cgi" )
+server.indexfiles = ( "gitweb.cgi" )
+server.pid-file = "$fqgitdir/pid"
+cgi.assign = ( ".cgi" => "" )
+mimetype.assign = ( ".css" => "text/css" )
+EOF
+ test "$local" = true && echo 'server.bind = "127.0.0.1"' >> "$conf"
+}
+
+apache2_conf () {
+ test -z "$module_path" && module_path=/usr/lib/apache2/modules
+ mkdir -p "$GIT_DIR/gitweb/logs"
+ bind=
+ test "$local" = true && bind='127.0.0.1:'
+ echo 'text/css css' > $fqgitdir/mime.types
+ cat > "$conf" <<EOF
+ServerRoot "$fqgitdir/gitweb"
+DocumentRoot "$fqgitdir/gitweb"
+PidFile "$fqgitdir/pid"
+Listen $bind$port
+TypesConfig $fqgitdir/mime.types
+DirectoryIndex gitweb.cgi
+EOF
+
+ # check to see if Dennis Stosberg's mod_perl compatibility patch
+ # (<20060621130708.Gcbc6e5c@leonov.stosberg.net>) has been applied
+ if test -f "$module_path/mod_perl.so" && grep '^our $gitbin' \
+ "$GIT_DIR/gitweb/gitweb.cgi" >/dev/null
+ then
+ # favor mod_perl if available
+ cat >> "$conf" <<EOF
+LoadModule perl_module $module_path/mod_perl.so
+PerlPassEnv GIT_DIR
+PerlPassEnv GIT_EXEC_DIR
+<Location /gitweb.cgi>
+ SetHandler perl-script
+ PerlResponseHandler ModPerl::Registry
+ PerlOptions +ParseHeaders
+ Options +ExecCGI
+</Location>
+EOF
+ else
+ # plain-old CGI
+ cat >> "$conf" <<EOF
+LoadModule cgi_module $module_path/mod_cgi.so
+AddHandler cgi-script .cgi
+<Location /gitweb.cgi>
+ Options +ExecCGI
+</Location>
+EOF
+ fi
+}
+
+script='
+s#^\(my\|our\) $projectroot =.*#\1 $projectroot = "'`dirname $fqgitdir`'";#;
+s#\(my\|our\) $gitbin =.*#\1 $gitbin = "'$GIT_EXEC_PATH'";#;
+s#\(my\|our\) $projects_list =.*#\1 $projects_list = $projectroot;#;
+s#\(my\|our\) $git_temp =.*#\1 $git_temp = "'$fqgitdir/gitweb/tmp'";#'
+
+gitweb_cgi () {
+ cat > "$1.tmp" <<\EOFGITWEB
+@@GITWEB_CGI@@
+EOFGITWEB
+ sed "$script" "$1.tmp" > "$1"
+ chmod +x "$1"
+ rm -f "$1.tmp"
+}
+
+gitweb_css () {
+ cat > "$1" <<\EOFGITWEB
+@@GITWEB_CSS@@
+EOFGITWEB
+}
+
+gitweb_cgi $GIT_DIR/gitweb/gitweb.cgi
+gitweb_css $GIT_DIR/gitweb/gitweb.css
+
+case "$httpd" in
+*lighttpd*)
+ lighttpd_conf
+ ;;
+*apache2*)
+ apache2_conf
+ ;;
+*)
+ echo "Unknown httpd specified: $httpd"
+ exit 1
+ ;;
+esac
+
+start_httpd
+test -z "$browser" && browser=echo
+$browser http://127.0.0.1:$port
--
1.4.1.rc2.gbf43
^ permalink raw reply related
* Re: A note on merging conflicts..
From: Daniel Barkalow @ 2006-07-01 22:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: J. Bruce Fields, Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607011115500.12404@g5.osdl.org>
On Sat, 1 Jul 2006, Linus Torvalds wrote:
> That said, it does have a real downside, and that's simply that it can
> take a long time to compute.
I think a...b can be computed by (in pseudocode, obviously):
mark(a, 1);
add(list, a);
mark(b, 2);
add(list, b);
while (interesting(list)) {
if (*list->marks != 3)
output(*list);
for (parent : *list->parents) {
mark(parent, *list->marks);
add(list, parent);
}
}
It's basically the original merge-bases code, from way back; the several
flaws with it for computing a good merge base don't matter if you're just
excluding the merge bases. If you look at the big examples in merge-base.c
(pre-libification), it's obvious that what we want for a...b is everything
marked 1 or 2, and the trickiness in that code is getting things correctly
marked 3 versus 7, which doesn't matter here.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Enable tree (directory) history display
From: Luben Tuikov @ 2006-07-01 22:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606302029310.12404@g5.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> That count of 145 is the number of commits that actually _change_ Makefile
> some way - and some of them really are merges, because they have a content
> merge, and the merge result is thus different from any of the children. So
> that's a real number. So is 136, in some sense - it just says that we
> don't care about commits, even if those commits _do_ end up changing the
> file.
Indeed, I got the same conclusion using different branches.
(Sorry, I thought your email was from Junio in my last email, it was
your analysis after all.)
> But the important part to realize is that the "971" number is always
> wrong. It's never a really valid number. It contains a lot of extra
> merges, but it does _not_ contain enough of them to connect all the dots,
> and it's thus never correct. Either you should drop merges that don't
> change things (in which case you cannot have full connectivity, and
> "--parents" doesn't make sense), or you should keep them all (or at least
> enough to get full connectivity).
Yes, that makes sense.
Ok, I get similar numbers as you do. After the patch, compared to
the simple case of git-rev-list HEAD -- <path spec>, --parents gives
me only one more commit which is the very first hand made kernel
commit ;-) ; --parents --full-history gives me way too many unrelated
commits about 10x as many; --full-history gives me a _complete_ list.
The simple case fails to report a few commits which are
due to merges, which do indeed change files in the path spec.
(--full-history successfully reported those though).
So your patch plus "--full-history" is what I think we want.
Luben
^ permalink raw reply
* Re: [PATCH/RFC] Add git-instaweb, instantly browse the working repo with gitweb
From: Bertrand Jacquin @ 2006-07-01 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <7vwtayh56z.fsf@assigned-by-dhcp.cox.net>
On 6/30/06, Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > I got tired of having to configure gitweb for every repository
> > I work on. I sometimes prefer gitweb to standard GUIs like gitk
> > or gitview; so this lets me automatically configure gitweb to
> > browse my working repository and also opens my browser to it.
> >
> > Signed-off-by: Eric Wong <normalperson@yhbt.net>
>
> This is cute but I haven't seen much responses to it yet. Are
> people uninterested?
I am.
--
# Beber : beber@gna.org
# IM : beber@jabber.fr
# http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
^ permalink raw reply
* (unknown),
From: Mark @ 2006-07-01 15:33 UTC (permalink / raw)
To: git
One of your friends used our send-to-a-friend-option: Check this out:
register for job alert, as well as i did - http://job-alert.net
^ permalink raw reply
* Re: A note on merging conflicts..
From: Linus Torvalds @ 2006-07-01 22:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: J. Bruce Fields, Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607011754370.9789@iabervon.org>
On Sat, 1 Jul 2006, Daniel Barkalow wrote:
>
> I think a...b can be computed by (in pseudocode, obviously):
Nope.
> It's basically the original merge-bases code, from way back;
And it has basically the same bug.
It is possible to have
a
/ \
b c
|\ /|
d e f
\|/
g
and clearly "e" is the only valid merge-base of b and c.
HOWEVER. It's actually possible that we traverse d, f and g before we even
look at 'e' (because somebody had a bogus date, and 'e' _looks_ old).
Remember: in a distributed system we have no global clock, so any graph
traversal ordering we choose is by definition always arbitrary, even
though we can obviously _try_ to choose one that is efficient in practice
(ie the "sort the heap by date).
So that's why git-merge-base has all that extra "unnecessary" complexity.
You cannot output anything at all until you've guaranteed that all pending
objects are uninteresting.
Linus
^ permalink raw reply
* Re: [PATCH] Add possibility to pass CFLAGS and LDFLAGS specific to the perl subdir
From: Petr Baudis @ 2006-07-01 22:59 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: Junio C Hamano, git
In-Reply-To: <20060626222308.G71066338@leonov.stosberg.net>
Dear diary, on Tue, Jun 27, 2006 at 12:23:08AM CEST, I got a letter
where Dennis Stosberg <dennis@stosberg.net> said that...
> Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
> ---
> Makefile | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index f44fbd3..306025d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -94,6 +94,8 @@ CFLAGS = -g -O2 -Wall
> LDFLAGS =
> ALL_CFLAGS = $(CFLAGS)
> ALL_LDFLAGS = $(LDFLAGS)
> +PERL_CFLAGS =
> +PERL_LDFLAGS =
> STRIP ?= strip
>
> prefix = $(HOME)
Just an annotation:
ALL_* means "use these flags for compilation of all the stuff
except perly stuff"
PERL_* means "use these flags for compilation of really all the
stuff"
So "all" might not mean what you think and Perl is stonger than
everything.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: A note on merging conflicts..
From: Johannes Schindelin @ 2006-07-01 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rene Scharfe, git
In-Reply-To: <7vzmftcd60.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 1 Jul 2006, Junio C Hamano wrote:
> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
> > I wonder why the two clear_commit_marks() calls at the end of
> > get_merge_bases() are not sufficient, though.
I wonder, too. In all of my tests, this call was sufficient to reset the
marks. I really wonder what happens here. At least one of the three flags
should be set in _any_ commit get_merge_bases() touches. Help!
> I missed to notice that Johannes had added those calls there; we
> should remove them from get_merge_bases().
As you hinted with your patch in another mail: no, we should not. Stuff
them into an if(), yes. But the point of a library function is not to make
it hard on users, but rather to make life easier. The user should _not_
have to investigate which loops to jump through to make use of this
function several times.
> The normal case of git-merge-base calling get_merge_bases() once
> and exiting should NOT have to pay for the clean-up cost at all.
Note that this was partly the reason for my hesitation to propose this
patch for inclusion already. If you make this function a library function,
the main user is _not_ git-merge-base any more. Everybody can use it from
now on.
Ciao,
Dscho
P.S.: I was having to much fun tonight to investigate in detail... Sorry.
^ permalink raw reply
* INVITATION.....................................................
From: Miss Violet Tesyi @ 2006-07-01 15:40 UTC (permalink / raw)
Dear Friend,
My name is Violet Tesyi, female, working with (WORLD YOUTH ORGANIZATION
FOR HUMAN WELFARE) California, U.S.A. We are organizing a global youths
combined conferences taking place from August 14th-16th 2006 at
California in the United States and in ,Dakar Senegal from August
21th-23th 2006 .In our request to invite people from various countries
around the world, I went in search of e-mails on the web site as a
means of contacting youths and organizations .
*As a result, I picked your e-mail from an N.G.O`s website. If you are interested
to participate and want to represent your country, you may contact the secretariat
of the organizing committee for details and information. You should also
inform them that you were invited to participate by a friend of yours (Violet Tesyi), who is a member of the American Youths 4 Peace and a staff of(WORLD YOUTH ORGANIZATION FOR HUMAN WELFARE).
I believe that we may have the opportunity to meet if you may be willing to participate
in this event. You can also inform youths & NGOs in your country about
these conferences.
The benevolent donors of the Organizing Committee will provide round trip air tickets and accommodation for the period of participants? stay in the U.S., to all registered participants. If you are a holder of passport that may require visa to enter the United States you may inform the conference secretariat at the time of registration, as the organizing committee is responsible for all visa arrangements and travel assistances. Below is the contact address of the conference secretariat (Miss Anny Morre).
EMAIL: icorcar112conferences@comic.com
By Tel/Fax: 1-425-671-3781
Please reply me Via: violet_usa_conference@yahoo.ca
Sincerely,
Violet Tesyi
^ permalink raw reply
* Re: A note on merging conflicts..
From: Daniel Barkalow @ 2006-07-01 23:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: J. Bruce Fields, Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607011552170.12404@g5.osdl.org>
On Sat, 1 Jul 2006, Linus Torvalds wrote:
> On Sat, 1 Jul 2006, Daniel Barkalow wrote:
> >
> > I think a...b can be computed by (in pseudocode, obviously):
>
> Nope.
>
> > It's basically the original merge-bases code, from way back;
>
> And it has basically the same bug.
>
> It is possible to have
>
> a
> / \
> b c
> |\ /|
> d e f
> \|/
> g
>
> and clearly "e" is the only valid merge-base of b and c.
>
> HOWEVER. It's actually possible that we traverse d, f and g before we even
> look at 'e' (because somebody had a bogus date, and 'e' _looks_ old).
But that wouldn't actually affect b...c, because we don't actually care
that 'e' is the correct merge-base and 'g' is not, because "b c ^e ^g" is
the same as "b c ^e".
Your point is correct, though; if we look at e before c, we could think
that it's interesting when it isn't, so we have to wait until we've
drained the list to output anything.
> So that's why git-merge-base has all that extra "unnecessary" complexity.
> You cannot output anything at all until you've guaranteed that all pending
> objects are uninteresting.
That's not all the complexity in git-merge-base, though. There's a ton
more that's about why e is right and g is wrong in your example, and we
don't care about *that* part in b...c.
Actually, I think that it would work to have object flags "LEFT" and
"RIGHT", mark b with left, mark c with right, and mark anything with both
LEFT and RIGHT as UNINTERESTING as we go through the revisions. The
time-ordering problem with symmetric difference isn't absent with regular
difference, and, assuming that b..c works in the tricky cases, the same
logic should handle symmetric difference.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH 1/3] Add get_merge_bases_clean()
From: Rene Scharfe @ 2006-07-01 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Linus Torvalds
In-Reply-To: <7vpsgpccak.fsf@assigned-by-dhcp.cox.net>
Add get_merge_bases_clean(), a wrapper for get_merge_bases() that cleans
up after doing its work and make get_merge_bases() NOT clean up.
Single-shot programs like git-merge-base can use the dirty and fast
version.
Also move the object flags used in get_merge_bases() out of the range
defined in revision.h. This fixes the "66ae0c77...ced9456a
89719209...262a6ef7" test of the ... operator which is introduced with
the next patch.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
All object flags should probably be gathered into one place to avoid
future conflicts.
commit.c | 20 ++++++++++++++++----
commit.h | 1 +
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/commit.c b/commit.c
index 0431027..593414d 100644
--- a/commit.c
+++ b/commit.c
@@ -849,9 +849,10 @@ void sort_in_topological_order_fn(struct
/* merge-rebase stuff */
-#define PARENT1 1
-#define PARENT2 2
-#define UNINTERESTING 4
+/* bits #0..7 in revision.h */
+#define PARENT1 (1u<< 8)
+#define PARENT2 (1u<< 9)
+#define UNINTERESTING (1u<<10)
static struct commit *interesting(struct commit_list *list)
{
@@ -1080,9 +1081,20 @@ struct commit_list *get_merge_bases(stru
tmp = next;
}
- /* reset flags */
+ return result;
+}
+
+struct commit_list *get_merge_bases_clean(struct commit *rev1,
+ struct commit *rev2)
+{
+ unsigned int flags1 = rev1->object.flags;
+ unsigned int flags2 = rev2->object.flags;
+ struct commit_list *result = get_merge_bases(rev1, rev2);
+
clear_commit_marks(rev1, PARENT1 | PARENT2 | UNINTERESTING);
clear_commit_marks(rev2, PARENT1 | PARENT2 | UNINTERESTING);
+ rev1->object.flags = flags1;
+ rev2->object.flags = flags2;
return result;
}
diff --git a/commit.h b/commit.h
index 89b9dad..3a26e29 100644
--- a/commit.h
+++ b/commit.h
@@ -106,5 +106,6 @@ int register_commit_graft(struct commit_
int read_graft_file(const char *graft_file);
extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2);
+extern struct commit_list *get_merge_bases_clean(struct commit *rev1, struct commit *rev2);
#endif /* COMMIT_H */
--
1.4.1.rc2.gfc04
^ permalink raw reply related
* [PATCH 2/3] Add '...' operator for revisions
From: Rene Scharfe @ 2006-07-01 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Linus Torvalds
In-Reply-To: <7vpsgpccak.fsf@assigned-by-dhcp.cox.net>
'A...B' is a shortcut for 'A B --not $(git-merge-base --all A B)'.
This XOR-like operation is called symmetric difference in set
theory.
The symbol '...' has been chosen because it's rather similar to the
existing '..' operator and the somewhat more natural caret ('^') is
already taken.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Documentation/git-rev-list.txt | 14 ++++++++++++
revision.c | 48 +++++++++++++++++++++++++++++++++-------
2 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index ad6d14c..6c370e1 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -15,6 +15,7 @@ SYNOPSIS
[ \--sparse ]
[ \--no-merges ]
[ \--remove-empty ]
+ [ \--not ]
[ \--all ]
[ \--topo-order ]
[ \--parents ]
@@ -37,6 +38,14 @@ not in 'baz'".
A special notation <commit1>..<commit2> can be used as a
short-hand for {caret}<commit1> <commit2>.
+Another special notation is <commit1>...<commit2> which is useful for
+merges. The resulting set of commits is the symmetric difference
+between the two operands. The following two commands are equivalent:
+
+------------
+$ git-rev-list A B --not $(git-merge-base --all A B)
+$ git-rev-list A...B
+------------
OPTIONS
-------
@@ -93,6 +102,11 @@ OPTIONS
--remove-empty::
Stop when a given path disappears from the tree.
+--not::
+ Reverses the meaning of the '{caret}' prefix (or lack
+ thereof) for all following revision specifiers, up to
+ the next `--not`.
+
--all::
Pretend as if all the refs in `$GIT_DIR/refs/` are
listed on the command line as <commit>.
diff --git a/revision.c b/revision.c
index b963f2a..9eb0b6d 100644
--- a/revision.c
+++ b/revision.c
@@ -536,6 +536,18 @@ void init_revisions(struct rev_info *rev
diff_setup(&revs->diffopt);
}
+static void add_pending_commit_list(struct rev_info *revs,
+ struct commit_list *commit_list,
+ unsigned int flags)
+{
+ while (commit_list) {
+ struct object *object = &commit_list->item->object;
+ object->flags |= flags;
+ add_pending_object(revs, object, sha1_to_hex(object->sha1));
+ commit_list = commit_list->next;
+ }
+}
+
/*
* Parse revision information, filling in the "rev_info" structure,
* and removing the used arguments from the argument list.
@@ -771,27 +783,45 @@ int setup_revisions(int argc, const char
unsigned char from_sha1[20];
const char *next = dotdot + 2;
const char *this = arg;
+ int symmetric = *next == '.';
+ unsigned int flags_exclude = flags ^ UNINTERESTING;
+
*dotdot = 0;
+ next += symmetric;
+
if (!*next)
next = "HEAD";
if (dotdot == arg)
this = "HEAD";
if (!get_sha1(this, from_sha1) &&
!get_sha1(next, sha1)) {
- struct object *exclude;
- struct object *include;
-
- exclude = get_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
- include = get_reference(revs, next, sha1, flags);
- if (!exclude || !include)
- die("Invalid revision range %s..%s", arg, next);
+ struct commit *a, *b;
+ struct commit_list *exclude;
+
+ a = lookup_commit_reference(from_sha1);
+ b = lookup_commit_reference(sha1);
+ if (!a || !b) {
+ die(symmetric ?
+ "Invalid symmetric difference expression %s...%s" :
+ "Invalid revision range %s..%s",
+ arg, next);
+ }
if (!seen_dashdash) {
*dotdot = '.';
verify_non_filename(revs->prefix, arg);
}
- add_pending_object(revs, exclude, this);
- add_pending_object(revs, include, next);
+
+ if (symmetric) {
+ exclude = get_merge_bases_clean(a, b);
+ add_pending_commit_list(revs, exclude,
+ flags_exclude);
+ a->object.flags |= flags;
+ } else
+ a->object.flags |= flags_exclude;
+ b->object.flags |= flags;
+ add_pending_object(revs, &a->object, this);
+ add_pending_object(revs, &b->object, next);
continue;
}
*dotdot = '.';
--
1.4.1.rc2.gfc04
^ permalink raw reply related
* [PATCH 3/3] Make clear_commit_marks() clean harder
From: Rene Scharfe @ 2006-07-01 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Linus Torvalds
In-Reply-To: <7vpsgpccak.fsf@assigned-by-dhcp.cox.net>
Don't care if objects have been parsed or not and don't stop when we
reach a commit that is already clean -- its parents could be dirty.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
commit.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/commit.c b/commit.c
index 593414d..70a4eff 100644
--- a/commit.c
+++ b/commit.c
@@ -397,13 +397,12 @@ void clear_commit_marks(struct commit *c
{
struct commit_list *parents;
+ if (!commit)
+ return;
parents = commit->parents;
commit->object.flags &= ~mark;
while (parents) {
- struct commit *parent = parents->item;
- if (parent && parent->object.parsed &&
- (parent->object.flags & mark))
- clear_commit_marks(parent, mark);
+ clear_commit_marks(parents->item, mark);
parents = parents->next;
}
}
--
1.4.1.rc2.gfc04
^ permalink raw reply related
* [PATCH] Git.pm: Remove PerlIO usage from Git.xs
From: Petr Baudis @ 2006-07-01 23:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
PerlIO_*() is not portable before 5.7.3, according to ppport.h, and it's
more clear what is going on when we do it in the Perl part of the Git module
anyway.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
perl/Git.pm | 14 +++++++++++++-
perl/Git.xs | 56 +++++++++++++++++++++++++-------------------------------
2 files changed, 38 insertions(+), 32 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 0581447..b4ee88b 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -511,7 +511,19 @@ are involved.
=cut
-# Implemented in Git.xs.
+sub hash_object {
+ my ($self, $type, $file) = _maybe_self(@_);
+
+ # hash_object_* implemented in Git.xs.
+
+ if (ref($file) eq 'GLOB') {
+ my $hash = hash_object_pipe($type, fileno($file));
+ close $file;
+ return $hash;
+ } else {
+ hash_object_file($type, $file);
+ }
+}
diff --git a/perl/Git.xs b/perl/Git.xs
index 3030ba9..cb23261 100644
--- a/perl/Git.xs
+++ b/perl/Git.xs
@@ -104,42 +104,36 @@ CODE:
}
char *
-xs_hash_object(type, file)
+xs_hash_object_pipe(type, fd)
char *type;
- SV *file;
+ int fd;
CODE:
{
unsigned char sha1[20];
- if (SvTYPE(file) == SVt_RV)
- file = SvRV(file);
-
- if (SvTYPE(file) == SVt_PVGV) {
- /* Filehandle */
- PerlIO *pio;
-
- pio = IoIFP(sv_2io(file));
- if (!pio)
- croak("You passed me something weird - a dir glob?");
- /* XXX: I just hope PerlIO didn't read anything from it yet.
- * --pasky */
- if (index_pipe(sha1, PerlIO_fileno(pio), type, 0))
- croak("Unable to hash given filehandle");
- /* Avoid any nasty surprises. */
- PerlIO_close(pio);
-
- } else {
- /* String */
- char *path = SvPV_nolen(file);
- int fd = open(path, O_RDONLY);
- struct stat st;
-
- if (fd < 0 ||
- fstat(fd, &st) < 0 ||
- index_fd(sha1, fd, &st, 0, type))
- croak("Unable to hash %s", path);
- close(fd);
- }
+ if (index_pipe(sha1, fd, type, 0))
+ croak("Unable to hash given filehandle");
+ RETVAL = sha1_to_hex(sha1);
+}
+OUTPUT:
+ RETVAL
+
+char *
+xs_hash_object_file(type, path)
+ char *type;
+ char *path;
+CODE:
+{
+ unsigned char sha1[20];
+ int fd = open(path, O_RDONLY);
+ struct stat st;
+
+ if (fd < 0 ||
+ fstat(fd, &st) < 0 ||
+ index_fd(sha1, fd, &st, 0, type))
+ croak("Unable to hash %s", path);
+ close(fd);
+
RETVAL = sha1_to_hex(sha1);
}
OUTPUT:
^ permalink raw reply related
* Re: [PATCH 1/3] Add get_merge_bases_clean()
From: Johannes Schindelin @ 2006-07-01 23:43 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <20060701232926.GA2513@lsrfire.ath.cx>
Hi,
On Sun, 2 Jul 2006, Rene Scharfe wrote:
> Also move the object flags used in get_merge_bases() out of the range
> defined in revision.h. This fixes the "66ae0c77...ced9456a
> 89719209...262a6ef7" test of the ... operator which is introduced with
> the next patch.
Of COURSE! *hits his head on the table; table breaks; has to buy a new
table*
Ciao,
Dscho
^ permalink raw reply
* Re: A note on merging conflicts..
From: Daniel Barkalow @ 2006-07-01 23:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: J. Bruce Fields, Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607011905030.9789@iabervon.org>
On Sat, 1 Jul 2006, Daniel Barkalow wrote:
> Actually, I think that it would work to have object flags "LEFT" and
> "RIGHT", mark b with left, mark c with right, and mark anything with both
> LEFT and RIGHT as UNINTERESTING as we go through the revisions. The
> time-ordering problem with symmetric difference isn't absent with regular
> difference, and, assuming that b..c works in the tricky cases, the same
> logic should handle symmetric difference.
That is: (this only has the logic portion, and it's against master, so it
isn't actually a really working patch or anything; also, it doesn't handle
"--not a...b" correctly, whatever that should mean)
---
diff --git a/revision.c b/revision.c
index 6a6952c..c21d332 100644
--- a/revision.c
+++ b/revision.c
@@ -351,6 +351,9 @@ static void add_parents_to_list(struct r
return;
commit->object.flags |= ADDED;
+ if (commit->object.flags & LEFT && commit->objects.flags & RIGHT)
+ commit->object.flags |= UNINTERESTING;
+
/*
* If the commit is uninteresting, don't try to
* prune parents - we want the maximal uninteresting
@@ -781,8 +784,13 @@ int setup_revisions(int argc, const char
struct object *exclude;
struct object *include;
- exclude = get_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
- include = get_reference(revs, next, sha1, flags);
+ if (symmetric) {
+ exclude = get_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
+ include = get_reference(revs, next, sha1, flags);
+ } else {
+ exclude = get_reference(revs, this, from_sha1, flags | LEFT_HALF);
+ include = get_reference(revs, next, sha1, flags | RIGHT_HALF);
+ }
if (!exclude || !include)
die("Invalid revision range %s..%s", arg, next);
diff --git a/revision.h b/revision.h
index 7d85b0f..93421e6 100644
--- a/revision.h
+++ b/revision.h
@@ -9,6 +9,8 @@
#define BOUNDARY (1u<<5)
#define BOUNDARY_SHOW (1u<<6)
#define ADDED (1u<<7) /* Parents already parsed and added? */
+#define LEFT_HALF (1u<<8) /* Reachable from start of dotdotdot */
+#define RIGHT_HALF (1u<<9) /* Reachable from end of dotdotdot */
struct rev_info;
struct log_info;
--
1.2.4
^ permalink raw reply related
* [PATCH] Git.pm: Avoid ppport.h
From: Petr Baudis @ 2006-07-01 23:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606280938420.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Wed, Jun 28, 2006 at 09:39:46AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> on my iBook, make in pu outputs:
>
> GIT_VERSION = 1.4.1.rc1.gf5d3
> * new build flags or prefix
> (cd perl && /usr/bin/perl Makefile.PL \
> PREFIX='/Users/gene099' \
> DEFINE=' -I/sw/include -DSHA1_HEADER='\''<openssl/sha.h>'\''
> -DNO_STRCASESTR -DNO_STRLCPY -DGIT_VERSION='\''"1.4.1.rc1.gf5d3"'\''' \
> LIBS=' -L/sw/lib -lz -liconv -lcrypto -lssl')
> Can't locate Devel/PPPort.pm in @INC (@INC contains:
> /System/Library/Perl/darwin /System/Library/Perl /Library/Perl/darwin
> /Library/Perl /Library/Perl /Network/Library/Perl/darwin
> /Network/Library/Perl /Network/Library/Perl .) at Makefile.PL line 29.
> BEGIN failed--compilation aborted at Makefile.PL line 29.
> make: *** [perl/Makefile] Error 2
ow, Devel::PPPort might not be around all the way back to 5.6.0. What
is your Perl version, BTW?
->8-
This makes us not include ppport.h which seems not to give us anything real
anyway; it is useful for checking for portability warts but since Devel::PPPort
is a portability wart itself, we shouldn't require it for build. You can check
for portability problems by calling make check in perl/.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
perl/Git.xs | 2 --
perl/Makefile.PL | 10 +++++-----
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/perl/Git.xs b/perl/Git.xs
index cb23261..51bfac3 100644
--- a/perl/Git.xs
+++ b/perl/Git.xs
@@ -15,8 +15,6 @@ #include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
-#include "ppport.h"
-
#undef die
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 25ae54a..97ee9af 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -5,6 +5,11 @@ sub MY::postamble {
instlibdir:
@echo '$(INSTALLSITEARCH)'
+check:
+ perl -MDevel::PPPort -le 'Devel::PPPort::WriteFile(".ppport.h")' && \
+ perl .ppport.h --compat-version=5.6.0 Git.xs && \
+ rm .ppport.h
+
MAKE_FRAG
}
@@ -24,8 +29,3 @@ WriteMakefile(
MYEXTLIB => '../libgit.a',
INC => '-I. -I..',
);
-
-
-use Devel::PPPort;
-
--s 'ppport.h' or Devel::PPPort::WriteFile();
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply related
* [POOL] Who likes running Git without make install?
From: Petr Baudis @ 2006-07-01 23:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk674mmyo.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> I remember myself getting utterly discusted when I saw the
> inclusion of the build-time blib directory in the search path in
> some other Perl code outside git.
Well, yes, it is ugly, but it was really cool that we could have used
Git without installing it anywhere.
But perhaps that's just me refusing to break his old ways of doing
things. Does anyone else care about it? (And why?)
> Worse yet, I suspect the order you do the two directories is
> wrong to prefer the freshly built one over the one you installed
> the last time, but I was trying not to stare at too much for
> health reasons so ... ;-).
Oh man, of course you are right. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Git at Ottawa Linux Symposium
From: Petr Baudis @ 2006-07-02 0:02 UTC (permalink / raw)
To: git; +Cc: junkio, jdl
Hi,
as a reminder and quick invitation, there will be quite some
Git-related stuff going on at the Ottawa Linux Symposium 2006 between
Jul 19 and Jul 22. The schedule is available at:
http://www.linuxsymposium.org/2006/schedule.php
Of particular interest for the local population should be the Git BOF
session on Wednesday afternoon that Junio and me will hold. If you want
to discuss Git as its users or as its developers, we are looking forward
to meet you.
Furthermore, on Thursday early afternoon there will be three Git
events in a row! First I will try to gently introduce (Co)git(o)
to the newbie audience, then in another room Junio will give a talk
about how Git feels like and how maintaining Git feels like, and then
the crowd will scurry back to the tutorial room to watch jdl showing
the raw power of lowlevel git unleashed.
Happy summer,
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [POOL] Who likes running Git without make install?
From: Junio C Hamano @ 2006-07-02 0:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060701235906.GE29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> I remember myself getting utterly discusted when I saw the
>> inclusion of the build-time blib directory in the search path in
>> some other Perl code outside git.
>
> Well, yes, it is ugly, but it was really cool that we could have used
> Git without installing it anywhere.
>
> But perhaps that's just me refusing to break his old ways of doing
> things. Does anyone else care about it? (And why?)
>
>> Worse yet, I suspect the order you do the two directories is
>> wrong to prefer the freshly built one over the one you installed
>> the last time, but I was trying not to stare at too much for
>> health reasons so ... ;-).
>
> Oh man, of course you are right. :-)
That's fixed in ancient past in git timescale. Why are you
bringing it up again? ;-)
^ permalink raw reply
* [PATCH] Minor documentation fixup.
From: Robin Rosenberg @ 2006-07-02 0:07 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Documentation/git-commit.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 0fe66f2..517a86b 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -15,9 +15,9 @@ SYNOPSIS
DESCRIPTION
-----------
Updates the index file for given paths, or all modified files if
-'-a' is specified, and makes a commit object. The command
-VISUAL and EDITOR environment variables to edit the commit log
-message.
+'-a' is specified, and makes a commit object. The command specified
+by either the VISUAL or EDITOR environment variables are used to edit
+the commit log message.
Several environment variable are used during commits. They are
documented in gitlink:git-commit-tree[1].
^ permalink raw reply related
* Re: [POOL] Who likes running Git without make install?
From: Junio C Hamano @ 2006-07-02 0:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060701235906.GE29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> I remember myself getting utterly discusted when I saw the
>> inclusion of the build-time blib directory in the search path in
>> some other Perl code outside git.
>
> Well, yes, it is ugly, but it was really cool that we could have used
> Git without installing it anywhere.
>
> But perhaps that's just me refusing to break his old ways of doing
> things. Does anyone else care about it? (And why?)
Well, for a quick test to see if I haven't broken anything, I
use a new shell and do ". ./+denv" in my git repository where
that file has something like this:
$ cat ./+denv
:
GIT_EXEC_PATH=`pwd`
PATH=`pwd`:/usr/bin:/bin
export GIT_EXEC_PATH PATH
So to a certain degree, yes I do care.
^ permalink raw reply
* Re: A note on merging conflicts..
From: Linus Torvalds @ 2006-07-02 0:08 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: J. Bruce Fields, Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607011905030.9789@iabervon.org>
On Sat, 1 Jul 2006, Daniel Barkalow wrote:
>
> But that wouldn't actually affect b...c, because we don't actually care
> that 'e' is the correct merge-base and 'g' is not, because "b c ^e ^g" is
> the same as "b c ^e".
You're right - in ths case we don't care about a minimal base commit set
at all, it's fine to have too many.
I think your patch to do the LEFT/RIGHT thing in git-rev-list internally,
instead of generating it as part of the command line, looks fine in
theory.
Except I think you need to set "revs->limited" for that case too (normally
it gets set by "handle_commit()", and only if there is an UNINTERESTING
commit: we'd need to add code to set it for LEFT/RIGHT commits too.
Linus
^ 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