* [PATCH] GIT-VERSION-GEN: detect dirty tree and mark the version accordingly.
From: Junio C Hamano @ 2006-01-10 2:53 UTC (permalink / raw)
To: git
If we are building from a working tree with local modifications,
mark the version accordingly.
Deliberately uses '-' to prevent RPM from being built from such
a tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is a useful precaution and should be safe, so planned to
go into 1.1.1.
GIT-VERSION-GEN | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
339b684aa42ac80964ef0d9049445dad7f83848c
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index c878819..cb393b5 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -11,6 +11,14 @@ set)
;;
esac
+dirty=$(sh -c 'git-diff-files --name-only HEAD' 2>/dev/null) || dirty=
+case "$dirty" in
+'')
+ ;;
+*)
+ VN="$VN-dirty" ;;
+esac
+
if test -r $GVF
then
VC=$(sed -e 's/^GIT_VERSION = //' <$GVF)
--
1.1.0
^ permalink raw reply related
* Re: git pull on Linux/ACPI release tree
From: Junio C Hamano @ 2006-01-10 3:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0601091845160.5588@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Now, obviously, for various reasons we want to avoid having those kinds of
> linkages as much as possible. We like to have develpment of different
> subsystems as independent as possible, not because it makes for a "more
> readable history", but because it makes it a lot easier to debug - if we
> have three independent features/development trees, they can be debugged
> independently too, while any linkages inevitably also mean that any bugs
> end up being interlinked..
>
> Linus
Yes. If subproject B uses new features from A (either upstream
or sibling subproject), pulling A into B is inevitable.
On the other hand, if such merges becomes too frequent, it may
be a sign that A's feature set and interface is still changing
too rapidly for downstream use, but developers A and B are not
communicating well and B has not noticed that B might be better
off taking a break, addressing other non-overlapping areas while
giving a bit of time for A to settle things down.
An SCM is just _one_ of the ways for developers to communicate,
it will never be a replacement for developer communication.
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: Junio C Hamano @ 2006-01-10 3:05 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43C31551.5010202@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Tarballs really should work as-is... the easy way to deal with that is
> to have the tarball make script generate a version file which isn't
> part of the git tree.
>
> I'll send a patch under a separate cover.
Thanks.
^ permalink raw reply
* Re: git-rename
From: David S. Miller @ 2006-01-10 4:40 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <7vvewtpwrq.fsf@assigned-by-dhcp.cox.net>
From: Junio C Hamano <junkio@cox.net>
Date: Mon, 09 Jan 2006 01:37:29 -0800
> I do not ship git-rename anymore. Doesn't your 'git status' say
> it is "untracked"?
Yes, it is untracked.
^ permalink raw reply
* Re: undoing changes with git-checkout -f
From: Joel Becker @ 2006-01-10 4:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: lamikr, git
In-Reply-To: <7vmzi5hy69.fsf@assigned-by-dhcp.cox.net>
On Mon, Jan 09, 2006 at 01:46:38PM -0800, Junio C Hamano wrote:
> Please do not use rsync:// transport if possible (mvista might
> only pubilsh via rsync:// and not git://, so it may not be your
> fault).
Can we teach the git:// fetch program to use CONNECT over HTTP
proxies? rsync can do this, but git:// cannot, so firewalls that block
9418 mean we use rsync://
I'm mostly offline this week or I'd take a stab at it.
Joel
--
"We will have to repent in this generation not merely for the
vitriolic words and actions of the bad people, but for the
appalling silence of the good people."
- Rev. Dr. Martin Luther King, Jr.
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: needs merge
From: Daniel Barkalow @ 2006-01-10 5:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brown, Len, git
In-Reply-To: <7vy81reoie.fsf@assigned-by-dhcp.cox.net>
On Sat, 7 Jan 2006, Junio C Hamano wrote:
> *1* While I was trying out the above scenario, I noticed that
> resolve strategy does not notice this and ended up picking one
> ancestor at random. I think this is because case #16 covers
> only the case where the path P is not changed between C and E
> and D and F, and case #11 must pick an ancestor and picks one at
> random. Daniel, any thoughts on this?
Right; in this case, we really want to use a merge program that takes
multiple ancestors and handles the equivalent to case #16 at the hunk
level, but we don't have such a program available. Such a program would be
able to identify whether case #16 ever actually occurs for a hunk, which
is important because there will generally be a bunch of case #11s at the
file level, even if there aren't any reverts (if the common ancestors
disagreed before, and the two branches both changed the file to something
entirely new, with no reverts, either ancestor is correct to use and the
merge result will be useful; we only need to be careful if there were
reverts somewhere, which leads to the possibility of false sharing between
a branch and an ancestor, and thereby to ignoring the revert, and my
feeling is that rejecting case #11 with divergant ancestors would lead to
too many conflicts to make crossing merges useable).
One possibility, actually, is to steal a trick from the recursive
strategy, and have a multi-ancestor merge program which merges all of the
ancestors with a merge-style diff (i.e., merge output, but on diff instead
of diff3, with all differences being conflicts), and then uses the result
as the ancestor for the three-way merge. It seems to me that this would
capture the central advantage of the recursive strategy without quite so
much work. Or I might be completely wrong; I'm kind of worn out, and may
not be thinking clearly.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: undoing changes with git-checkout -f
From: Junio C Hamano @ 2006-01-10 5:57 UTC (permalink / raw)
To: Joel Becker; +Cc: lamikr, git
In-Reply-To: <20060110045533.GO18439@ca-server1.us.oracle.com>
Joel Becker <Joel.Becker@oracle.com> writes:
> Can we teach the git:// fetch program to use CONNECT over HTTP
> proxies? rsync can do this, but git:// cannot, so firewalls that block
> 9418 mean we use rsync://
> I'm mostly offline this week or I'd take a stab at it.
It's been there for quite some time, although I never liked the
way it interfaces with the outside world.
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
gitproxy = /usr/local/bin/tn-gw-nav-local
$ cat /usr/local/bin/tn-gw-nav-local
#!/bin/sh
# Use squid running at localhost
exec tn-gw-nav -H -h 127.0.0.1 -p 3128 "$1" "$2"
$ grep SSL /etc/squid/squid.conf
acl SSL_ports 443 563 9418 # https snntp git
http_access deny CONNECT !SSL_ports
$ git fetch --tags git://git.kernel.org/pub/scm/git/git.git/
It is a bit inconvenient that "git clone" wrapper cannot be used
on an existing repository, and without an existing repository
you cannot have .git/config. You could have the config file in
your site-wide template area, but admittably it is a bit
awkward.
^ permalink raw reply
* Re: undoing changes with git-checkout -f
From: Joel Becker @ 2006-01-10 6:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: lamikr, git
In-Reply-To: <7vk6d8aaln.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]
On Mon, Jan 09, 2006 at 09:57:40PM -0800, Junio C Hamano wrote:
> Joel Becker <Joel.Becker@oracle.com> writes:
> > Can we teach the git:// fetch program to use CONNECT over HTTP
> > proxies? rsync can do this, but git:// cannot, so firewalls that block
> > 9418 mean we use rsync://
> > I'm mostly offline this week or I'd take a stab at it.
>
> It's been there for quite some time, although I never liked the
> way it interfaces with the outside world.
>
Ugly snipped...
> It is a bit inconvenient that "git clone" wrapper cannot be used
> on an existing repository, and without an existing repository
> you cannot have .git/config. You could have the config file in
> your site-wide template area, but admittably it is a bit
> awkward.
Here's what I did. I modified the usual
ssh-tunnel-over-SSL-CONNECT script to honor http_proxy. I've attached
it. With this, I do as so:
# cp git-tunnel.pl /usr/local/bin
# export http_proxy="http://my-proxy.my.com:80/"
# GIT_PROXY_COMMAND="/usr/local/bin/git-tunnel.pl" git clone git://git.kernel.org/pub/scm/... localsource
# cd localsource
# vi .git/config
[core]
gitproxy = /usr/local/bin/git-tunnel.pl
This is working for me. I'd really rather have the tunneling
code be part of connect.c, and have core.proxymethod=external use the
current core.gitproxy method and core.proxymethod=http use $http_proxy.
But this will suffice for now :-)
Joel
--
Life's Little Instruction Book #198
"Feed a stranger's expired parking meter."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
[-- Attachment #2: git-tunnel.pl --]
[-- Type: text/x-perl, Size: 2667 bytes --]
#!/usr/bin/perl
#
# git-tunnel.pl
#
# Usage: git-tunnel.pl ssl-proxy port destination_host port
#
# This script can be used by git as a "core.gitproxy" to
# traverse a www-proxy/firewall that supports the http CONNECT
# command described in
# http://home.netscape.com/newsref/std/tunneling_ssl.html
#
# It uses the http_proxy (or HTTP_PROXY) variable to determine the
# proxy to connect to. Put the path to this script in the environment
# variable GIT_PROXY_COMMAND, or better yet, insert the core.gitproxy
# definition in .git/config.
#
# .
# .
# [core]
# gitproxy = /path/to/git-tunnel.pl
# .
# .
#
# Written by Urban Kaveus <urban@statt.ericsson.se>
# Modified to use http_proxy by Joel Becker <joel.becker@oracle.com>
use Socket;
# Parse command line arguments
if ( $#ARGV != 1 ) {
print STDERR "Usage: $0 destination port\n";
print STDERR $#ARGV, "\n";
exit(1);
}
$proxy_url = $ENV{'http_proxy'};
if (!$proxy_url) {
$proxy_url = $ENV{'HTTP_PROXY'};
}
$proxyport = 80;
if ($proxy_url =~ /^https?:\/\/([^:]+)\/$/) {
$sslproxy = $1;
} elsif ($proxy_url =~ /^https?:\/\/([^:]+):([1-9][0-9]*)\/$/) {
$sslproxy = $1;
$proxyport = $2;
} else {
print STDERR "Invalid proxy specification: \"$proxy_url\"\n";
exit(1);
}
$destination = shift;
$destport = shift;
# Set up network communication
($protocol) = (getprotobyname("tcp"))[2];
($proxyip) = (gethostbyname($sslproxy))[4];
$localaddr = pack('S n a4 x8', &AF_INET, 0, "\0\0\0\0");
$proxyaddr = pack('S n a4 x8', &AF_INET, $proxyport, $proxyip);
socket (PROXY, &AF_INET, &SOCK_STREAM, $protocol) or
die("Failed to create cocket");
bind (PROXY, $localaddr) or
die("Failed to bind socket");
connect (PROXY, $proxyaddr) or
die("Failed to connect to $sslproxy port $proxyport");
# Force flushing of socket buffers
select (PROXY); $| = 1;
select (STDOUT); $| = 1;
# Send a "CONNECT" command to proxy:
print PROXY "CONNECT $destination:$destport HTTP/1.1\r\n\r\n";
# Wait for HTTP status code, bail out if you don't get back a 2xx code.
$_ = <PROXY>;
($status) = (split())[1];
die("Received a bad status code \"$status\" from proxy server")
if ( int($status/100) != 2 );
# Skip through remaining part of MIME header
while(<PROXY>) {
chomp; # Strip <LF>
last if /^[\r]*$/; # Empty line or a single <CR> left
}
# Start copying packets in both directions.
if($child = fork) { # Parent process
while (sysread(STDIN,$_,4096)) {
print PROXY;
}
sleep 2;
kill(15,$child) if $child;
}
else { # Child process
while (sysread(PROXY,$_,4096)) {
print STDOUT;
}
}
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Kyle Moffett @ 2006-01-10 6:33 UTC (permalink / raw)
To: Luben Tuikov
Cc: Brown, Len, Luck, Tony, Junio C Hamano, Martin Langhoff,
Linus Torvalds, David S. Miller,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, LKML Kernel, Andrew Morton,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601091845160.5588-hNm40g4Ew95AfugRpC6u6w@public.gmane.org>
On Jan 09, 2006, at 21:50, Linus Torvalds wrote:
> if we have three independent features/development trees, they can
> be debugged independently too, while any linkages inevitably also
> mean that any bugs end up being interlinked..
One example:
If I have ACPI, netdev, and swsusp trees change between an older
version and a newer one, and my net driver starts breaking during
suspend, I would be happiest debugging with the following set of
patches/trees (Heavily simplified):
^
|
[5]
|
broken
^ ^ ^
[2] [3] [4]
/ | \
netdev3 acpi3 swsusp3
^ ^ ^
| | |
netdev2 acpi2 swsusp2
^ ^ ^
| | |
netdev1 acpi1 swsusp1
^ ^ ^
\ | /
\ | /
\ | /
\|/
|
[1]
|
works
If the old version [1] works and the new one [5] doesn't, then I can
immediately test [2], [3], and [4]. If one of those doesn't work,
I've identified the problematic patchset and cut the debugging by
2/3. If they all work, then we know precisely that it's the
interactions between them, which also makes debugging a lot easier.
Cheers,
Kyle Moffett
--
There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
-- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Martin Langhoff @ 2006-01-10 6:38 UTC (permalink / raw)
To: Kyle Moffett
Cc: Luben Tuikov, Brown, Len, Luck, Tony, Junio C Hamano,
Linus Torvalds, David S. Miller,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, LKML Kernel, Andrew Morton,
Git Mailing List
In-Reply-To: <99D82C29-4F19-4DD3-A961-698C3FC0631D-ee4meeAH724@public.gmane.org>
On 1/10/06, Kyle Moffett <mrmacman_g4-ee4meeAH724@public.gmane.org> wrote:
> If they all work, then we know precisely that it's the
> interactions between them, which also makes debugging a lot easier.
The more complex your tree structure is, the more the interactions are
likely to be part of the problem. Is git-bisect not useful in this
scenario?
cheers,
martin
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: undoing changes with git-checkout -f
From: Joel Becker @ 2006-01-10 7:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: lamikr, git
In-Reply-To: <20060110063247.GP18439@ca-server1.us.oracle.com>
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
On Mon, Jan 09, 2006 at 10:32:47PM -0800, Joel Becker wrote:
> Here's what I did. I modified the usual
> ssh-tunnel-over-SSL-CONNECT script to honor http_proxy. I've attached
> it. With this, I do as so:
Bug in the script closing one side of the connection. Corrected
version attached.
Joel
--
"I'm drifting and drifting
Just like a ship out on the sea.
Cause I ain't got nobody, baby,
In this world to care for me."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
[-- Attachment #2: git-tunnel.pl --]
[-- Type: text/x-perl, Size: 2715 bytes --]
#!/usr/bin/perl
#
# git-tunnel.pl
#
# Usage: git-tunnel.pl ssl-proxy port destination_host port
#
# This script can be used by git as a "core.gitproxy" to
# traverse a www-proxy/firewall that supports the http CONNECT
# command described in
# http://home.netscape.com/newsref/std/tunneling_ssl.html
#
# It uses the http_proxy (or HTTP_PROXY) variable to determine the
# proxy to connect to. Put the path to this script in the environment
# variable GIT_PROXY_COMMAND, or better yet, insert the core.gitproxy
# definition in .git/config.
#
# .
# .
# [core]
# gitproxy = /path/to/git-tunnel.pl
# .
# .
#
# Written by Urban Kaveus <urban@statt.ericsson.se>
# Modified to use http_proxy by Joel Becker <joel.becker@oracle.com>
use Socket;
# Parse command line arguments
if ( $#ARGV != 1 ) {
print STDERR "Usage: $0 destination port\n";
print STDERR $#ARGV, "\n";
exit(1);
}
$proxy_url = $ENV{'http_proxy'};
if (!$proxy_url) {
$proxy_url = $ENV{'HTTP_PROXY'};
}
$proxyport = 80;
if ($proxy_url =~ /^https?:\/\/([^:]+)\/$/) {
$sslproxy = $1;
} elsif ($proxy_url =~ /^https?:\/\/([^:]+):([1-9][0-9]*)\/$/) {
$sslproxy = $1;
$proxyport = $2;
} else {
print STDERR "Invalid proxy specification: \"$proxy_url\"\n";
exit(1);
}
$destination = shift;
$destport = shift;
# Set up network communication
($protocol) = (getprotobyname("tcp"))[2];
($proxyip) = (gethostbyname($sslproxy))[4];
$localaddr = pack('S n a4 x8', &AF_INET, 0, "\0\0\0\0");
$proxyaddr = pack('S n a4 x8', &AF_INET, $proxyport, $proxyip);
socket (PROXY, &AF_INET, &SOCK_STREAM, $protocol) or
die("Failed to create cocket");
bind (PROXY, $localaddr) or
die("Failed to bind socket");
connect (PROXY, $proxyaddr) or
die("Failed to connect to $sslproxy port $proxyport");
# Force flushing of socket buffers
select (PROXY); $| = 1;
select (STDOUT); $| = 1;
# Send a "CONNECT" command to proxy:
print PROXY "CONNECT $destination:$destport HTTP/1.1\r\n\r\n";
# Wait for HTTP status code, bail out if you don't get back a 2xx code.
$_ = <PROXY>;
($status) = (split())[1];
die("Received a bad status code \"$status\" from proxy server")
if ( int($status/100) != 2 );
# Skip through remaining part of MIME header
while(<PROXY>) {
chomp; # Strip <LF>
last if /^[\r]*$/; # Empty line or a single <CR> left
}
# Start copying packets in both directions.
$parent = $$;
if($child = fork) { # Parent process
while (sysread(STDIN,$_,4096)) {
print PROXY;
}
sleep 2;
kill(15,$child) if $child;
}
else { # Child process
while (sysread(PROXY,$_,4096)) {
print STDOUT;
}
sleep 2;
kill(15,$parent);
}
^ permalink raw reply
* Re: undoing changes with git-checkout -f
From: Junio C Hamano @ 2006-01-10 7:42 UTC (permalink / raw)
To: Joel Becker; +Cc: git
In-Reply-To: <20060110063247.GP18439@ca-server1.us.oracle.com>
Joel Becker <Joel.Becker@oracle.com> writes:
> ... I'd really rather have the tunneling
> code be part of connect.c,...
For the record, I was pushing for that, but that approach was
interrupted primarily by what this message implies:
http://article.gmane.org/gmane.comp.version-control.git/10985
The thread that originally introduced the current proxy is here:
http://thread.gmane.org/gmane.comp.version-control.git/11074
^ permalink raw reply
* Re: undoing changes with git-checkout -f
From: Joel Becker @ 2006-01-10 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy81o8r6n.fsf@assigned-by-dhcp.cox.net>
On Mon, Jan 09, 2006 at 11:42:24PM -0800, Junio C Hamano wrote:
> Joel Becker <Joel.Becker@oracle.com> writes:
> > ... I'd really rather have the tunneling
> > code be part of connect.c,...
>
> For the record, I was pushing for that, but that approach was
> interrupted primarily by what this message implies:
>
> http://article.gmane.org/gmane.comp.version-control.git/10985
Yeah, we want to handle multiple things. Well, I've got it
working with git-tunnel.pl, so I'm happy enough not to be using rsync://
:-)
Joel
--
Life's Little Instruction Book #139
"Never deprive someone of hope; it might be all they have."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* killing a branch
From: Jens Axboe @ 2006-01-10 10:22 UTC (permalink / raw)
To: git
Hi,
When I need to delete a branch from my git tree, I'm currently using
this (slooow) approach:
$ rm .git/refs/heads/branch-name
$ git prune
to rid myself of the branch and associated objects. Is there a faster
approach?
(please cc me, not on the list)
--
Jens Axboe
^ permalink raw reply
* Re: killing a branch
From: Junio C Hamano @ 2006-01-10 10:25 UTC (permalink / raw)
To: Jens Axboe; +Cc: git
In-Reply-To: <20060110102207.GP3389@suse.de>
Jens Axboe <axboe@suse.de> writes:
> $ rm .git/refs/heads/branch-name
> $ git prune
>
> to rid myself of the branch and associated objects. Is there a faster
> approach?
Perhaps the "official" way is
$ git branch -d branch-name ;# you may need -D
$ git prune
but that essentially is the same as what you are doing. Note
that having dangling objects in your repository is not a crime,
and you do not have to religiously do "git prune" every time.
^ permalink raw reply
* Re: killing a branch
From: Jens Axboe @ 2006-01-10 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr77g8jm4.fsf@assigned-by-dhcp.cox.net>
On Tue, Jan 10 2006, Junio C Hamano wrote:
> Jens Axboe <axboe@suse.de> writes:
>
> > $ rm .git/refs/heads/branch-name
> > $ git prune
> >
> > to rid myself of the branch and associated objects. Is there a faster
> > approach?
>
> Perhaps the "official" way is
>
> $ git branch -d branch-name ;# you may need -D
> $ git prune
>
> but that essentially is the same as what you are doing. Note
So no time saved there :-)
> that having dangling objects in your repository is not a crime,
> and you do not have to religiously do "git prune" every time.
I know, it just doesn't feel nice!
--
Jens Axboe
^ permalink raw reply
* Re: killing a branch
From: Junio C Hamano @ 2006-01-10 10:52 UTC (permalink / raw)
To: Jens Axboe; +Cc: git
In-Reply-To: <20060110103533.GT3389@suse.de>
Jens Axboe <axboe@suse.de> writes:
>> that having dangling objects in your repository is not a crime,
>> and you do not have to religiously do "git prune" every time.
>
> I know, it just doesn't feel nice!
Sorry, but I can think of only three reasons (and a half) why
somebody cannot live with "one git prune at the end of the day
before leaving" (or "week" for that matter) workflow:
* the filesystem quota is too tight and you cannot afford to
leave unused loose objects around. May still be true on
student accounts, perhaps, but I doubt this is much of an
issue in the modern world anymore.
* rsync is used to sync from a repository that dropped a branch
just now, and you do not want to push the garbage out. Well,
if you are still using rsync, I'll tell about it to Linus ;-)
Pushing via git native protocol over ssh would not send
unreferenced objects out and will not contaminate the other
end with the garbage.
* you do not want to leave after starting prune before it
finishes. If it is your hobby to watch the paint dry, I
cannot help you, but you could run prune under nohup (or
always work inside "screen", which is what I do).
+ having unused things on the disk just does not _feel_ right.
Well, maybe. I can argue with a reason but not with a
feeling. On a bright side, leaving recently abandoned
objects around for a while lets you run git-lost-found to
recover if you accidentally deleted a still-useful branch.
^ permalink raw reply
* Re: killing a branch
From: Jens Axboe @ 2006-01-10 11:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy81o73t2.fsf@assigned-by-dhcp.cox.net>
On Tue, Jan 10 2006, Junio C Hamano wrote:
> Jens Axboe <axboe@suse.de> writes:
>
> >> that having dangling objects in your repository is not a crime,
> >> and you do not have to religiously do "git prune" every time.
> >
> > I know, it just doesn't feel nice!
>
> Sorry, but I can think of only three reasons (and a half) why
> somebody cannot live with "one git prune at the end of the day
> before leaving" (or "week" for that matter) workflow:
>
> * the filesystem quota is too tight and you cannot afford to
> leave unused loose objects around. May still be true on
> student accounts, perhaps, but I doubt this is much of an
> issue in the modern world anymore.
Yeah obviously not true.
> * rsync is used to sync from a repository that dropped a branch
> just now, and you do not want to push the garbage out. Well,
> if you are still using rsync, I'll tell about it to Linus ;-)
> Pushing via git native protocol over ssh would not send
> unreferenced objects out and will not contaminate the other
> end with the garbage.
Haven't used rsync in a long time, I use git:// and ssh:// exclusively.
> * you do not want to leave after starting prune before it
> finishes. If it is your hobby to watch the paint dry, I
> cannot help you, but you could run prune under nohup (or
> always work inside "screen", which is what I do).
>
> + having unused things on the disk just does not _feel_ right.
> Well, maybe. I can argue with a reason but not with a
> feeling. On a bright side, leaving recently abandoned
> objects around for a while lets you run git-lost-found to
> recover if you accidentally deleted a still-useful branch.
:-)
Alright, I'll just have to shake the habit of running git prune to rid
myself of that dirty dirty feeling.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Michal Ostrowski @ 2006-01-10 13:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwth8bxqd.fsf@assigned-by-dhcp.cox.net>
On Mon, 2006-01-09 at 18:52 -0800, Junio C Hamano wrote:
> Michal Ostrowski <mostrows@watson.ibm.com> writes:
>
> > Calls to git_setup_exec_path() are inserted on paths that will execute
> > other git programs. git_setup_exec_path() will ensure that the git
> > installation directories are in the path.
>
> About fetch-clone.c (which is shared by fetch-pack and
> clone-pack), it runs "git-index-pack" from finish_pack and
> "git-unpack-objects" from unpack_pack, so spelling these exec
> with execlp("git", "git", "index-pack", ...) might be cleaner,
> since "git" is required to be in users' PATH even though git-*
> may be moved out of the PATH in later versions of git. I
> dunno...
>
> In send-pack.c, I wonder why you didn't do a setup_exec_path()
> at the beginning of main() instead of having two calls close to
> exec*() call site.
>
> The same comment applies for run-command.c; you do it once for
> each child, but calling it once at the beginning of receive-pack
> would be good enough. The same thing for daemon.c.
>
> I suspect you are trying to limit the extent of damage, but I do
> not think of a downside if we just call setup_exec_path() once
> at the beginning of main(). $GIT_EXEC_PATH _could_ have a
> private copy of broken "diff" to confuse diff-* family, but you
> cannot say "git diff" in such a setup anyway because "git" does
> the PATH prefixing already, so it would be a moot point.
>
I'm not actually happy with the idea of mucking around with PATH, even
within git.c. Hence I tried to only change PATH if the code had already
committed to an exec.
An approach that I think is better is to require all exec's of git
programs from within git programs to use a specific git interface,
rather than letting each one set up it's own exec parameters.
Once you have that implemented, we can have a separate discussion of how
the executable is to be found;
- should we use PATH?
- should we change PATH?
- should we always exec using an absolute file name? (my preference)
If a user invokes /home/user/bin/git-foo, and git-foo wants to call
git-bar, is it legitimate for git-foo to call /usr/local/bin/git-bar, or
should it require /home/user/bin/git-bar?
Should the same rules be applied to the shell scripts? (In which case
we'd want to do something like s:git-:$(GIT_EXEC_PATH)/git-:g.)
Anyways, it may just be easier to show this in C (patch below).
--
Michal Ostrowski <mostrows@watson.ibm.com>
diff --git a/Makefile b/Makefile
index c9c15b5..db57858 100644
--- a/Makefile
+++ b/Makefile
@@ -173,7 +173,7 @@ DIFF_OBJS = \
LIB_OBJS = \
blob.o commit.o connect.o count-delta.o csum-file.o \
- date.o diff-delta.o entry.o ident.o index.o \
+ date.o diff-delta.o entry.o exec_cmd.o ident.o index.o \
object.o pack-check.o patch-delta.o path.o pkt-line.o \
quote.o read-cache.o refs.o run-command.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
@@ -184,6 +184,16 @@ LIB_OBJS = \
LIBS = $(LIB_FILE)
LIBS += -lz
+
+# .exec_cmd.bindir stores $(bindir) used to compile exec_cmd.o
+# If it has changed, store the new value and force exec_cmd.o to be
rebuilt
+ifneq ($(shell cat .exec_cmd.bindir 2>/dev/null),$(bindir))
+.PHONY: exec_cmd.c
+$(shell echo $(bindir) > .exec_cmd.bindir)
+endif
+
+exec_cmd.o: CFLAGS+=-DGIT_EXEC_PATH=\"$(bindir)\"
+
# Shell quote;
# Result of this needs to be placed inside ''
shq = $(subst ','\'',$(1))
diff --git a/daemon.c b/daemon.c
index 3bd1426..ab793bd 100644
--- a/daemon.c
+++ b/daemon.c
@@ -9,6 +9,7 @@
#include <syslog.h>
#include "pkt-line.h"
#include "cache.h"
+#include "exec_cmd.h"
static int log_syslog;
static int verbose;
@@ -227,7 +228,7 @@ static int upload(char *dir)
snprintf(timeout_buf, sizeof timeout_buf, "--timeout=%u", timeout);
/* git-upload-pack only ever reads stuff, so this is safe */
- execlp("git-upload-pack", "git-upload-pack", "--strict", timeout_buf,
".", NULL);
+ exec_git_cmd("upload-pack", "--strict", timeout_buf, ".");
return -1;
}
diff --git a/fetch-clone.c b/fetch-clone.c
index f46fe6e..5ae9bda 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -1,4 +1,5 @@
#include "cache.h"
+#include "exec_cmd.h"
#include <sys/wait.h>
static int finish_pack(const char *pack_tmp_name, const char *me)
@@ -27,8 +28,7 @@ static int finish_pack(const char *pack_
dup2(pipe_fd[1], 1);
close(pipe_fd[0]);
close(pipe_fd[1]);
- execlp("git-index-pack","git-index-pack",
- "-o", idx, pack_tmp_name, NULL);
+ exec_git_cmd("index-pack", "-o", idx, pack_tmp_name);
error("cannot exec git-index-pack <%s> <%s>",
idx, pack_tmp_name);
exit(1);
@@ -105,8 +105,7 @@ int receive_unpack_pack(int fd[2], const
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execlp("git-unpack-objects", "git-unpack-objects",
- quiet ? "-q" : NULL, NULL);
+ exec_git_cmd("unpack-objects", quiet ? "-q" : NULL);
die("git-unpack-objects exec failed");
}
close(fd[0]);
diff --git a/git.c b/git.c
index 5e7da74..a45dc54 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@
#include <stdarg.h>
#include <sys/ioctl.h>
#include "git-compat-util.h"
+#include "exec_cmd.h"
#ifndef PATH_MAX
# define PATH_MAX 4096
@@ -192,25 +193,6 @@ static void cmd_usage(const char *exec_p
exit(1);
}
-static void prepend_to_path(const char *dir, int len)
-{
- char *path, *old_path = getenv("PATH");
- int path_len = len;
-
- if (!old_path)
- old_path = "/usr/local/bin:/usr/bin:/bin";
-
- path_len = len + strlen(old_path) + 1;
-
- path = malloc(path_len + 1);
-
- memcpy(path, dir, len);
- path[len] = ':';
- memcpy(path + len + 1, old_path, path_len - len);
-
- setenv("PATH", path, 1);
-}
-
static void show_man_page(char *git_cmd)
{
char *page;
@@ -233,14 +215,10 @@ int main(int argc, char **argv, char **e
{
char git_command[PATH_MAX + 1];
char wd[PATH_MAX + 1];
- int i, len, show_help = 0;
- char *exec_path = getenv("GIT_EXEC_PATH");
+ int i, show_help = 0;
getcwd(wd, PATH_MAX);
- if (!exec_path)
- exec_path = GIT_EXEC_PATH;
-
for (i = 1; i < argc; i++) {
char *arg = argv[i];
@@ -257,9 +235,9 @@ int main(int argc, char **argv, char **e
if (!strncmp(arg, "exec-path", 9)) {
arg += 9;
if (*arg == '=')
- exec_path = arg + 1;
+ git_set_exec_path(arg + 1);
else {
- puts(exec_path);
+ puts(git_exec_path());
exit(0);
}
}
@@ -275,48 +253,18 @@ int main(int argc, char **argv, char **e
if (i >= argc || show_help) {
if (i >= argc)
- cmd_usage(exec_path, NULL);
+ cmd_usage(git_exec_path(), NULL);
show_man_page(argv[i]);
}
- if (*exec_path != '/') {
- if (!getcwd(git_command, sizeof(git_command))) {
- fprintf(stderr,
- "git: cannot determine current directory\n");
- exit(1);
- }
- len = strlen(git_command);
-
- /* Trivial cleanup */
- while (!strncmp(exec_path, "./", 2)) {
- exec_path += 2;
- while (*exec_path == '/')
- exec_path++;
- }
- snprintf(git_command + len, sizeof(git_command) - len,
- "/%s", exec_path);
- }
- else
- strcpy(git_command, exec_path);
- len = strlen(git_command);
- prepend_to_path(git_command, len);
-
- len += snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[i]);
- if (sizeof(git_command) <= len) {
- fprintf(stderr, "git: command name given is too long.\n");
- exit(1);
- }
-
- /* execve() can only ever return if it fails */
- execve(git_command, &argv[i], envp);
+ execv_git_cmd(argv + i);
if (errno == ENOENT)
- cmd_usage(exec_path, "'%s' is not a git-command", argv[i]);
+ cmd_usage(git_exec_path(), "'%s' is not a git-command",
+ argv[i]);
fprintf(stderr, "Failed to run command '%s': %s\n",
git_command, strerror(errno));
-
return 1;
}
diff --git a/receive-pack.c b/receive-pack.c
index f847ec2..8e78e32 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -257,7 +257,7 @@ static void read_head_info(void)
static const char *unpack(int *error_code)
{
- int code = run_command(unpacker, NULL);
+ int code = run_command_v_opt(1, &unpacker, RUN_GIT_CMD);
*error_code = 0;
switch (code) {
diff --git a/run-command.c b/run-command.c
index 8bf5922..b3d287e 100644
--- a/run-command.c
+++ b/run-command.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "run-command.h"
#include <sys/wait.h>
+#include "exec_cmd.h"
int run_command_v_opt(int argc, char **argv, int flags)
{
@@ -13,9 +14,13 @@ int run_command_v_opt(int argc, char **a
int fd = open("/dev/null", O_RDWR);
dup2(fd, 0);
dup2(fd, 1);
- close(fd);
+ close(fd);
+ }
+ if (flags & RUN_GIT_CMD) {
+ execv_git_cmd(argv);
+ } else {
+ execvp(argv[0], (char *const*) argv);
}
- execvp(argv[0], (char *const*) argv);
die("exec %s failed.", argv[0]);
}
for (;;) {
diff --git a/run-command.h b/run-command.h
index 2469eea..ef3ee05 100644
--- a/run-command.h
+++ b/run-command.h
@@ -12,7 +12,7 @@ enum {
};
#define RUN_COMMAND_NO_STDIO 1
-
+#define RUN_GIT_CMD 2 /*If this is to be git sub-command */
int run_command_v_opt(int argc, char **argv, int opt);
int run_command_v(int argc, char **argv);
int run_command(const char *cmd, ...);
diff --git a/shell.c b/shell.c
index cd31618..0d4891f 100644
--- a/shell.c
+++ b/shell.c
@@ -12,7 +12,7 @@ static int do_generic_cmd(const char *me
my_argv[1] = arg;
my_argv[2] = NULL;
- return execvp(me, (char**) my_argv);
+ return execv_git_cmd((char**) my_argv);
}
static struct commands {
diff --git a/upload-pack.c b/upload-pack.c
index 1834b6b..6602d68 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -4,6 +4,7 @@
#include "tag.h"
#include "object.h"
#include "commit.h"
+#include "exec_cmd.h"
static const char upload_pack_usage[] = "git-upload-pack [--strict]
[--timeout=nn] <dir>";
@@ -60,7 +61,7 @@ static void create_pack_file(void)
close(0);
close(fd[0]);
close(fd[1]);
- *p++ = "git-rev-list";
+ *p++ = "rev-list";
*p++ = "--objects";
if (create_full_pack || MAX_NEEDS <= nr_needs)
*p++ = "--all";
@@ -79,13 +80,13 @@ static void create_pack_file(void)
buf += 41;
}
*p++ = NULL;
- execvp("git-rev-list", argv);
+ execv_git_cmd(argv);
die("git-upload-pack: unable to exec git-rev-list");
}
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execlp("git-pack-objects", "git-pack-objects", "--stdout", NULL);
+ exec_git_cmd("pack-objects", "--stdout");
die("git-upload-pack: unable to exec git-pack-objects");
}
^ permalink raw reply related
* Re: [ANNOUCNE] GIT 1.1.0
From: Johannes Schindelin @ 2006-01-10 14:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7v1wzgg9nm.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 9 Jan 2006, Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > I have no solution to this, apart from rewriting the Makefile on the
> > fly whenever a release tarball is created.
>
> Well, there is always an option to update the fallback version
> number hardcoded in GIT-VERSION-GEN script, but that kind fo
> defeats the whole idea of the current setup, so...
The whole idea of the current setup is working only if you have a git
repository of git. Kind of a chicken-egg, right?
So, why not just include GIT-VERSION-FILE in the tarball, and let
GIT-VERSION-GEN check if there exists .git or $GIT_DIR before trying its
voodoo?
---
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 845b9dc..b65b214 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -2,6 +2,9 @@
GVF=GIT-VERSION-FILE
+test -z "$GIT_DIR" && GIT_DIR=.git
+test -d "$GIT_DIR" || exit 0
+
VN=$(git-describe --abbrev=4 HEAD 2>/dev/null) || VN=v1.0.GIT
VN=$(expr "$VN" : v'\(.*\)')
if test -r $GVF
^ permalink raw reply related
* Re: undoing changes with git-checkout -f
From: Johannes Schindelin @ 2006-01-10 14:51 UTC (permalink / raw)
To: Joel Becker; +Cc: Junio C Hamano, git
In-Reply-To: <20060110045533.GO18439@ca-server1.us.oracle.com>
Hi,
On Mon, 9 Jan 2006, Joel Becker wrote:
> On Mon, Jan 09, 2006 at 01:46:38PM -0800, Junio C Hamano wrote:
> > Please do not use rsync:// transport if possible (mvista might
> > only pubilsh via rsync:// and not git://, so it may not be your
> > fault).
>
> Can we teach the git:// fetch program to use CONNECT over HTTP
> proxies? rsync can do this, but git:// cannot, so firewalls that block
> 9418 mean we use rsync://
I think it is good and well with the proxy command support. Everybody can
write a little script.
Otherwise, where would it end? If you include http_proxy functionality in
git, why not also https_proxy functionality? And if that, why not
IP-over-SMTP?
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Andreas Ericsson @ 2006-01-10 15:01 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: Junio C Hamano, git
In-Reply-To: <1136900174.11717.537.camel@brick.watson.ibm.com>
Michal Ostrowski wrote:
> On Mon, 2006-01-09 at 18:52 -0800, Junio C Hamano wrote:
>
>>About fetch-clone.c (which is shared by fetch-pack and
>>clone-pack), it runs "git-index-pack" from finish_pack and
>>"git-unpack-objects" from unpack_pack, so spelling these exec
>>with execlp("git", "git", "index-pack", ...) might be cleaner,
>>since "git" is required to be in users' PATH even though git-*
>>may be moved out of the PATH in later versions of git. I
>>dunno...
>>
>>In send-pack.c, I wonder why you didn't do a setup_exec_path()
>>at the beginning of main() instead of having two calls close to
>>exec*() call site.
>>
>>The same comment applies for run-command.c; you do it once for
>>each child, but calling it once at the beginning of receive-pack
>>would be good enough. The same thing for daemon.c.
>>
>>I suspect you are trying to limit the extent of damage, but I do
>>not think of a downside if we just call setup_exec_path() once
>>at the beginning of main(). $GIT_EXEC_PATH _could_ have a
>>private copy of broken "diff" to confuse diff-* family, but you
>>cannot say "git diff" in such a setup anyway because "git" does
>>the PATH prefixing already, so it would be a moot point.
>>
>
>
> I'm not actually happy with the idea of mucking around with PATH, even
> within git.c. Hence I tried to only change PATH if the code had already
> committed to an exec.
>
This is the case in the git potty already. git.c must prepend
--exec-path to $PATH, or the whole idea of being able to move scripts
out of the $PATH fails (at least it fails without changing quite a few
of the scripts).
Since it's already in place in the potty and that's required to be in
the $PATH, I think Junio's suggestion of running execlp("git", "git",
...) is a good one. It will add one extra fork() and execve() for each
clone/pull/push, but that isn't much of an issue, really.
> An approach that I think is better is to require all exec's of git
> programs from within git programs to use a specific git interface,
> rather than letting each one set up it's own exec parameters.
>
A better idea would be to teach {send,upload}-pack about $GIT_EXEX_PATH
and export it from your shells rc-file.
> Once you have that implemented, we can have a separate discussion of how
> the executable is to be found;
> - should we use PATH?
> - should we change PATH?
> - should we always exec using an absolute file name? (my preference)
>
> If a user invokes /home/user/bin/git-foo, and git-foo wants to call
> git-bar, is it legitimate for git-foo to call /usr/local/bin/git-bar, or
> should it require /home/user/bin/git-bar?
>
If a user invokes "/home/user/bin/git-foo" rather than
"/home/user/bin/git foo" he/she will have to have the rest of the
git-suite in the $PATH. Prepending whatever directory any git-* program
happens to reside in to $PATH is not a good idea. Trying to execute
programs residing in the same directory is an even worse.
> Should the same rules be applied to the shell scripts? (In which case
> we'd want to do something like s:git-:$(GIT_EXEC_PATH)/git-:g.)
>
All shell-scripts (that I'm aware of) are porcelainish. They should be
run through the git potty and thus should always run the git-programs
from the same release as they themselves were built from regardless of
whether they call them through the potty or directly. This is both sane
and simple. It was also one of the reasons that the 'git' program was
implemented in C to begin with.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Catalin Marinas @ 2006-01-08 8:16 UTC (permalink / raw)
To: len.brown; +Cc: torvalds, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A13489@hdsmsx401.amr.corp.intel.com>
"Brown, Len" wrote:
>>I _really_ wish you wouldn't have those automatic merges.
>>
>>Why do you do them? They add nothing but ugly and unnecessary
>>history, and in this pull, I think almost exactly half of the
>>commits were just these empty merges.
>
> Is it possible for it git, like bk, to simply ignore merge commits
> in its summary output?
As Junio suggested, you can have a look at StGIT
(http://www.procode.org/stgit/) for a different workflow. There is a
tutorial both on the web and in the doc/ directory but, anyway, it is
pretty similar to Quilt only that the patches are GIT commits.
In principle, you keep all the patches in a stack whose base is the
HEAD of Linus' kernel. You can indefinitely modify/push/pop the
patches and, once you are happy with the state of the stack, ask Linus
to pull using standard GIT commands (or mail them with 'stg
mail'). You can afterwards pull the latest changes from Linus using
'stg pull'. This operation pops the patches you have, advances the
base of the stack (so no "merge" message) and pushes your patches
back. Since pushing is done with a three-way merge, it detects whether
there are any upstream modifications to your patches (if not, all the
patches should become empty and safely removed from the stack).
You can also have a branch for upstream merges only and you can easily
cherry-pick patches or commits from other branches. This is quite
useful if you want to continue the work on your development branch
until Linus merges your patches.
--
Catalin
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Alex Riesen @ 2006-01-10 15:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Brown, Len, Luck, Tony, Martin Langhoff,
David S. Miller, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <7vu0cdjhd1.fsf-u5dp/1a/izZijMVVUgEtmwqrb7wDvxM8@public.gmane.org>
On 1/9/06, Junio C Hamano <junkio-j9pdmedNgrk@public.gmane.org> wrote:
> 2. Fix "git checkout <branch>" so that it does a reasonable thing
> even when a dirty path is different in current HEAD and
> destination branch. Then I could:
>
> $ git checkout symref ;# this would not work in the current git
> # it would die like this:
> # $ git checkout symref
> # fatal: Entry 'gitweb.cgi' not uptodate. Cannot merge.
That is actually very interesting. I already wished sometimes to be
able to switch branches with a dirty working directory (and usually
ended up with git diff+checkout+apply).
Even if it results in a merge and conflict markers in files it looks
like a very practical idea!
> $ git diff ;# just to make sure inevitable automated merge
> # did the right thing
> $ git commit -a -m "Fix symref fix"
> # I could collapse them into one instead, like this:
> # $ git reset --soft HEAD^
> # $ git commit -a -C ORIG_HEAD
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: undoing changes with git-checkout -f
From: Alex Riesen @ 2006-01-10 16:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Joel Becker, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0601101549360.26054@wbgn013.biozentrum.uni-wuerzburg.de>
On 1/10/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Can we teach the git:// fetch program to use CONNECT over HTTP
> > proxies? rsync can do this, but git:// cannot, so firewalls that block
> > 9418 mean we use rsync://
>
> I think it is good and well with the proxy command support. Everybody can
> write a little script.
>
> Otherwise, where would it end? If you include http_proxy functionality in
> git, why not also https_proxy functionality? And if that, why not
And, BTW, why not? It may as well stop here.
^ 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