* Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Daniel Barkalow @ 2008-06-29 18:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Pieter de Bie, Git Mailinglist
In-Reply-To: <7vvdzuo61b.fsf@gitster.siamese.dyndns.org>
On Fri, 27 Jun 2008, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > On Fri, 27 Jun 2008, Johannes Schindelin wrote:
> >
> >> After initializing the config in the newly-created repository, we
> >> need to unset GIT_CONFIG so that the global configs are read again.
> >
> > This seems fine to me. OTOH, I'm not sure the environment variable should
> > be needed in the first place; I think the config stuff should look in
> > git_path("config") without it, and we set the git dir to the one we're
> > initializing. So I think the use of the environment variable is just an
> > artifact of how the shell script did it and how I was originally calling
> > the init_db stuff.
> >
> > Just removing the "setenv()" line survives all of the tests for me, and I
> > remember some of them failing before I'd gotten some sort of solution for
> > the config stuff.
>
> Ok, I take that you are Ok with 2/2 but you have a better replacement
> patch coming for this 1/2?
I think so. Did we even make a commitment on whether:
GIT_CONFIG=foo git clone bar
must ignore the environment variable, or simply doesn't necessarily obey
it? IIRC, the test scripts used to set GIT_CONFIG to something
problematic (and would fail if clone didn't ignore it), but this was
deemed incorrect usage and fixed.
If it's okay to obey it (i.e., it gives the location of the config file
for the clone):
------
Use all of the normal config-file handling in builtin-clone.c
There's no need to use the environment variable to direct the generation
of the config file in the C version of clone, and having it not defined
means that global and per-user configuration is available. This is
necessary for the fetching portion, and could be useful someday for the
init portion as well. It is unlikely that the user would want the
repository's configuration in some non-default location, but no less
likely than with any other git command besides "git config".
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
diff --git a/builtin-clone.c b/builtin-clone.c
index f13845f..6dd58ac 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -415,8 +415,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
atexit(remove_junk);
signal(SIGINT, remove_junk_on_signal);
- setenv(CONFIG_ENVIRONMENT, xstrdup(mkpath("%s/config", git_dir)), 1);
-
if (safe_create_leading_directories_const(git_dir) < 0)
die("could not create leading directories of '%s'", git_dir);
set_git_dir(make_absolute_path(git_dir));
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Linus Torvalds @ 2008-06-29 18:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod5kd3im.fsf@gitster.siamese.dyndns.org>
On Sun, 29 Jun 2008, Junio C Hamano wrote:
>
> * /usr/bin/git-cat-file is no more. The bulk of the git commands will
> move to /usr/libexec/git-core/ or somesuch.
Every time I read this note I do a double-take.
To me, the first sentence means that 'cat-file' command is gone. Then, the
second sentence is just gibberish. And since I understand what you _want_
to say, I then go back and parse it properly, and know that you don't
actually mean that git-cat-file is removed, but that it's removed from
being accessible under that name in the path.
So to avoid my double-take, and hopefully avoid confusion for other
people, can you please make your status report rephrase that thing.
Maybe just say
* Do not install all git subcommands as 'git-xyzzy' files in the user
path. This avoids unnecessary hardlinks (or copies on systems that do
not support links), and enforces the 'git xyzzy' syntax.
Subcommands that aren't builtins now get installed in
/usr/libexec/git-core/ or somesuch.
(I haven't looked at the series, but I _assume_ it also avoids installing
the builtin subcommands entirely when not necessary, ie "git-cat-file"
really _is_ gone, but it's not because the "cat-file" command itself is
gone).
Hmm? Or maybe it's just me who gets confused by the phrasing.
Linus
^ permalink raw reply
* Re: Using url.insteadOf in git-clone
From: Pieter de Bie @ 2008-06-29 18:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailinglist, Daniel Barkalow
In-Reply-To: <7vbq1msszw.fsf@gitster.siamese.dyndns.org>
On 27 jun 2008, at 19:11, Junio C Hamano wrote:
> Pieter de Bie <pdebie@ai.rug.nl> writes:
>
>> [1] This is not really true. If I try that, I get an error:
>> Vienna:git pieter$ git fetch -v repo:dscho.git
>> fatal: I don't handle protocol 'it'
>>
>> If I change the url to "ggit://.." it does work. It seems there is an
>> off-by-one
>> error somewhere? It does work for another url.insteadOf I have in my
>> global
>> config though..
>
> What version of git is this?
>
> v1.5.5.1 and later contains 60e3aba (Fix config key miscount in
> url.*.insteadOf, 2008-04-12).
>
I think I tried this while testing the 1.5.5 clone.sh, so that's
probably it.
Thanks.
- Pieter
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-06-29 19:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0806291127140.21402@hp.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Maybe just say
>
> * Do not install all git subcommands as 'git-xyzzy' files in the user
> path. This avoids unnecessary hardlinks (or copies on systems that do
> not support links), and enforces the 'git xyzzy' syntax.
>
> Subcommands that aren't builtins now get installed in
> /usr/libexec/git-core/ or somesuch.
Thanks.
> (I haven't looked at the series, but I _assume_ it also avoids installing
> the builtin subcommands entirely when not necessary, ie "git-cat-file"
> really _is_ gone, but it's not because the "cat-file" command itself is
> gone).
It is actually a fairly long road ahead.
In 1.6.0, most of them will be moved to /usr/libexec/git-core/, so that
really old scripts end users may have can be more easily kept working by
simply saying:
PATH=$(git --exec-path):$PATH
early, without doing "s/git-/git /g".
Current git clients run git-upload-pack and friends in "git-xyzzy" form
when accessing remote repositories directly over ssh, so in 1.6.0 we will
have to leave these server side programs in $(bindir) as well.
git-shell and gitosis is being updated to accept "git upload-pack" form as
well, and after older versions of these programs die out, we can update
the clients to ask for remote side programs without dash.
None of the server side programs is built-in, so we could start the
hardlink removal independent from this transition (iow, "Only subcommands
that aren't builtin will be installed in libexec, builtins are not on the
disk anywhere" could happen now), but I'd prefer to keep changes in each
steps small to minimize impacts to the end users' environments.
^ permalink raw reply
* Re: [RFC/PATCH] Documentation: Don't assume git-sh-setup and git-parse-remote are in the PATH
From: Junio C Hamano @ 2008-06-29 19:08 UTC (permalink / raw)
To: jrnieder; +Cc: git, Alex Riesen, Jeff King
In-Reply-To: <Pine.GSO.4.62.0806291026310.8371@harper.uchicago.edu>
jrnieder@uchicago.edu writes:
> How about this documentation patch? (This time tested! With hg-fast-export
> appropriately modified:
> $ hg clone http://hg.sharesource.org/asciidoc
> $ mkdir asciidoc-git && cd asciidoc-git
> $ git init && hg-fast-export.sh -r /path/to/asciidoc --quiet
> $ git checkout
> $ sudo ./install.sh
> $ cd /path/to/git/Documentation && make git-{sh-setup,parse-remote}.html
> I haven't tried rebuilding manpages, though.)
>
> Junio: I stole the commit message from you. I hope you don't mind.
I don't, but reading the script again, I suspect it is not clear enough
that the user is also responsible for setting up GIT_DIR appropriately
before using it, perhaps by sourcing git-sh-setup. We probably would want
to add it in a separate patch.
^ permalink raw reply
* Re: [PATCH] Teach git-merge to pass -X<option> to the backend strategy module
From: Junio C Hamano @ 2008-06-29 19:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <g47oc3$q1l$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> diff --git a/git-merge.sh b/git-merge.sh
>> index 39b5cd9..d475852 100755
>> --- a/git-merge.sh
>> +++ b/git-merge.sh
>> @@ -17,6 +17,7 @@ commit perform a commit if the merge succeeds (default)
>> ff allow fast forward (default)
>> s,strategy= merge strategy to use
>> m,message= message to be used for the merge commit (if any)
>> +X= pass merge strategy specific options
>> "
>
> You have updated usage for git-merge, but didn't update manpages
> (Documentation).
Patches welcome ;-)
^ permalink raw reply
* perl t9700 failures?
From: Linus Torvalds @ 2008-06-29 19:52 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Lea Wiemann
Am I the only one who gets this error:
*** t9700-perl-git.sh ***
* ok 1: set up test repository
* run 2: Perl API (perl ../t9700/test.pl)
* FAIL 2: Perl API
perl ../t9700/test.pl
* FAIL 3: no stderr: Perl API
perl ../t9700/test.pl
* failed 2 among 3 test(s)
which I have no idea about, since to me perl is a black box, and doing
run of the tests with '-i -v' doesn't actually tell any more about which
part of the perl script is failing, or why.. Trying to run the perl thing
by hand, though, gives me this:
Can't locate Test/More.pm in @INC (@INC contains: ...)
which is presumably the problem. It looks like it is assuming I have the
Test::More perl libs, which I presumably don't have, don't have any clue
where they are, nor really any interest in installing.
Wouldn't it be a lot more polite to just not run the test when the
Test::More stuff doesn't exist? Rather than failing the testsuite? From a
quick "git grep", this test is the only one that uses Test::More..
Linus
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-06-29 20:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0806291127140.21402@hp.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> To me, the first sentence means that 'cat-file' command is gone....
Here is a replacement I am preparing, taken from the draft release notes
to 1.6.0:
* With the default Makefile settings, most of the programs will be
installed outside your $PATH, except for "git", "gitk", "git-gui" and
some server side programs that need to be accessible for technical
reasons. Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH will still be supported in
1.6.0, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.
^ permalink raw reply
* Re: [PATCH 2/2] clone: respect url.insteadOf setting in global configs
From: Pieter de Bie @ 2008-06-29 20:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist
In-Reply-To: <alpine.DEB.1.00.0806271355520.9925@racer>
On 27 jun 2008, at 14:56, Johannes Schindelin wrote:
> When we call "git clone" with a url that has a rewrite rule in either
> $HOME/.gitconfig or /etc/gitconfig, the URL can be different from
> what the command line expects it to be.
>
> So, let's use the URL as the remote structure has it, not the literal
> string from the command line.
>
> Noticed by Pieter de Bie.
This works great, thanks for the quick patch! :)
- Pieter
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Pieter de Bie @ 2008-06-29 20:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailinglist
In-Reply-To: <7vk5g89f34.fsf@gitster.siamese.dyndns.org>
On 29 jun 2008, at 22:11, Junio C Hamano wrote:
> use of them from your scripts after adding
> output from "git --exec-path" to the $PATH will still be supported
> in
> 1.6.0, but users are again strongly encouraged to adjust their
> scripts to use "git xyzzy" form, as we will stop installing
> "git-xyzzy" hardlinks for built-in commands in later releases.
I think msysgit doesn't (didn't?) install the hardlinks to conserve
space,
as Windows doesn't support hard links. Perhaps we should mention that
as well?
- Pieter
^ permalink raw reply
* Re: [PATCH 11/15] Add strbuf_vaddf(), use it in strbuf_addf(), and add strbuf_initf()
From: Alex Riesen @ 2008-06-29 20:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Miklos Vajna, git, Olivier Marin
In-Reply-To: <alpine.DEB.1.00.0806291436520.9925@racer>
Johannes Schindelin, Sun, Jun 29, 2008 15:40:57 +0200:
> On Sun, 29 Jun 2008, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Anyway, I'm fine with having them only in my personal fork.
> >
> > It will cost you some "trust point" next time you try to sneak something
> > in as a part of a largely unrelated topic. Please don't.
>
> Fine. Fine!
>
See the positive side: you just won a "please review me carefully"
point. These have no negative side effects, usually.
^ permalink raw reply
* Re: perl t9700 failures?
From: Junio C Hamano @ 2008-06-29 20:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Lea Wiemann
In-Reply-To: <alpine.LFD.1.10.0806291241210.27776@hp.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Am I the only one who gets this error:
>
> *** t9700-perl-git.sh ***
> * ok 1: set up test repository
> * run 2: Perl API (perl ../t9700/test.pl)
> * FAIL 2: Perl API
> perl ../t9700/test.pl
> * FAIL 3: no stderr: Perl API
> perl ../t9700/test.pl
> * failed 2 among 3 test(s)
>
> which I have no idea about, since to me perl is a black box, and doing
> run of the tests with '-i -v' doesn't actually tell any more about which
> part of the perl script is failing, or why.. Trying to run the perl thing
> by hand, though, gives me this:
>
> Can't locate Test/More.pm in @INC (@INC contains: ...)
>
> which is presumably the problem. It looks like it is assuming I have the
> Test::More perl libs, which I presumably don't have, don't have any clue
> where they are, nor really any interest in installing.
>
> Wouldn't it be a lot more polite to just not run the test when the
> Test::More stuff doesn't exist? Rather than failing the testsuite? From a
> quick "git grep", this test is the only one that uses Test::More..
Hmm. I was told that Test::More was part of the std Perl distribution
(and my quick check showed I happened to have that installed on my boxes
even though I do not use it myself and assumed it was there because the
claim is true). Another test that does rely on more obscure Perl library
does refrain from running when it is not available, though...
Perlhaps something liek this should be sufficient.
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index b2fb9ec..9b57ad1 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -6,6 +6,11 @@
test_description='perl interface (Git.pm)'
. ./test-lib.sh
+perl -MTest::More -e 0 2>/dev/null || {
+ say_color skip >&3 "Perl Test::More not available, skipping test"
+ test_done
+}
+
# set up test repository
test_expect_success \
^ permalink raw reply related
* Re: perl t9700 failures?
From: Junio C Hamano @ 2008-06-29 20:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Lea Wiemann
In-Reply-To: <alpine.LFD.1.10.0806291241210.27776@hp.linux-foundation.org>
I'll commit this (which is simpler than "Perlhaps this would suffice"
patch I sent earlier). Thanks for noticing.
-- >8 --
[PATCH] t9700: skip when Test::More is not available
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t9700-perl-git.sh | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index b2fb9ec..5dd32f4 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -6,6 +6,11 @@
test_description='perl interface (Git.pm)'
. ./test-lib.sh
+perl -MTest::More -e 0 2>/dev/null || {
+ say skip "Perl Test::More unavailable, skipping test"
+ test_done
+}
+
# set up test repository
test_expect_success \
--
1.5.6.1.102.g8e69d
^ permalink raw reply related
* Re: [PATCH 11/15] Add strbuf_vaddf(), use it in strbuf_addf(), and add strbuf_initf()
From: Junio C Hamano @ 2008-06-29 20:24 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, Miklos Vajna, git, Olivier Marin
In-Reply-To: <20080629201757.GA27370@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Johannes Schindelin, Sun, Jun 29, 2008 15:40:57 +0200:
>> On Sun, 29 Jun 2008, Junio C Hamano wrote:
>> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> >
>> > > Anyway, I'm fine with having them only in my personal fork.
>> >
>> > It will cost you some "trust point" next time you try to sneak something
>> > in as a part of a largely unrelated topic. Please don't.
>>
>> Fine. Fine!
>
> See the positive side: you just won a "please review me carefully"
> point. These have no negative side effects, usually.
Heh, he hasn't _yet_. I said "next time" didn't I?
^ permalink raw reply
* Re: [PATCH 11/15] Add strbuf_vaddf(), use it in strbuf_addf(), and add strbuf_initf()
From: Sverre Rabbelier @ 2008-06-29 20:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Alex Riesen, Johannes Schindelin, Miklos Vajna, git,
Olivier Marin
In-Reply-To: <7vvdzs7zwx.fsf@gitster.siamese.dyndns.org>
On Sun, Jun 29, 2008 at 10:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Heh, he hasn't _yet_. I said "next time" didn't I?
Now you sound like the bad guy from "Inspector Gadget" :P. "Next time
Dscho, next time!!!"
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] Skip Perl interface (Git.pm) tests if requirements not fullfilled
From: Jakub Narebski @ 2008-06-29 20:32 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Lea Wiemann, Jakub Narebski
In-Reply-To: <alpine.LFD.1.10.0806291241210.27776@hp.linux-foundation.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Linus Torvalds wrote:
> Wouldn't it be a lot more polite to just not run the test when the
> Test::More stuff doesn't exist? Rather than failing the testsuite? From a
> quick "git grep", this test is the only one that uses Test::More...
Would this be enough?
t/t9700-perl-git.sh | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index b2fb9ec..81ff84d 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -6,6 +6,18 @@
test_description='perl interface (Git.pm)'
. ./test-lib.sh
+perl -MTest::More -e '' >/dev/null 2>&1 || {
+ test_expect_success 'skipping Git.pm tests, Test::More module not found' :
+ test_done
+ exit
+}
+
+perl -e 'use 5.006002;' >/dev/null 2>&1 || {
+ test_expect_success 'skipping Git.pm tests, Perl version too old' :
+ test_done
+ exit
+}
+
# set up test repository
test_expect_success \
--
1.5.6
^ permalink raw reply related
* Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Junio C Hamano @ 2008-06-29 20:36 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, Pieter de Bie, Git Mailinglist
In-Reply-To: <alpine.LNX.1.00.0806291359330.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> There's no need to use the environment variable to direct the generation
> of the config file in the C version of clone, and having it not defined
> means that global and per-user configuration is available. This is
> necessary for the fetching portion, and could be useful someday for the
> init portion as well. It is unlikely that the user would want the
> repository's configuration in some non-default location, but no less
> likely than with any other git command besides "git config".
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Thanks, will queue together with the earlier [2/2] from Dscho.
Can we have updates to the testsuite as well? We would probably have to
fudge $HOME and have some entries in $HOME/.gitconfig to simulate the
situation that triggered the original discussion.
^ permalink raw reply
* [PATCH] Fix t4017-diff-retval for white-space from wc
From: Brian Gernhardt @ 2008-06-29 20:49 UTC (permalink / raw)
To: Git List
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
t/t4017-diff-retval.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Also: we have t4017-diff-retval and t4017-quiet. Should one of
these be renamed?
diff --git a/t/t4017-diff-retval.sh b/t/t4017-diff-retval.sh
index d748d45..60dd201 100755
--- a/t/t4017-diff-retval.sh
+++ b/t/t4017-diff-retval.sh
@@ -123,7 +123,7 @@ test_expect_success 'check detects leftover conflict markers' '
git --no-pager diff --cached --check >test.out
test $? = 2
) &&
- test "$(grep "conflict marker" test.out | wc -l)" = 3 &&
+ test 3 = $(grep "conflict marker" test.out | wc -l) &&
git reset --hard
'
--
1.5.6.105.g6f4b
^ permalink raw reply related
* [PATCH] Add test results directory to t/.gitignore
From: Brian Gernhardt @ 2008-06-29 20:47 UTC (permalink / raw)
To: Git List
We don't need test results to be committed if we're fixing a test.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
t/.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/.gitignore b/t/.gitignore
index 11ffd91..b27e280 100644
--- a/t/.gitignore
+++ b/t/.gitignore
@@ -1 +1,2 @@
/trash directory
+/test-results
--
1.5.6.105.g6f4b
^ permalink raw reply related
* Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Johannes Schindelin @ 2008-06-29 21:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Pieter de Bie, Git Mailinglist
In-Reply-To: <alpine.LNX.1.00.0806291359330.19665@iabervon.org>
Hi,
On Sun, 29 Jun 2008, Daniel Barkalow wrote:
> Did we even make a commitment on whether:
>
> GIT_CONFIG=foo git clone bar
>
> must ignore the environment variable, or simply doesn't necessarily obey
> it?
I'd rather strongly argue that no matter what is the answer to this
question, we _HAVE TO_ unsetenv() GIT_CONFIG at some stage, otherwise no
.git/config will be written.
So, this is a NACK on your patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] clone: respect url.insteadOf setting in global configs
From: Johannes Schindelin @ 2008-06-29 21:50 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Git Mailinglist
In-Reply-To: <770C18A6-429E-49C0-BCF3-C2B229AAF5F9@ai.rug.nl>
Hi,
On Sun, 29 Jun 2008, Pieter de Bie wrote:
> On 27 jun 2008, at 14:56, Johannes Schindelin wrote:
>
> > When we call "git clone" with a url that has a rewrite rule in either
> > $HOME/.gitconfig or /etc/gitconfig, the URL can be different from
> > what the command line expects it to be.
> >
> > So, let's use the URL as the remote structure has it, not the literal
> > string from the command line.
> >
> > Noticed by Pieter de Bie.
>
>
> This works great, thanks for the quick patch! :)
Thanks for the quick answer,
Dscho
^ permalink raw reply
* Re: [StGIT PATCH 1/4] Allow e-mails to be sent with the Unix sendmail tool
From: Catalin Marinas @ 2008-06-29 21:55 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080622151026.GA4468@diana.vm.bytemark.co.uk>
2008/6/22 Karl Hasselström <kha@treskal.com>:
> On 2008-06-19 22:42:01 +0100, Catalin Marinas wrote:
>> class GitConfig:
>> __defaults={
>> 'stgit.autoresolved': 'no',
>> - 'stgit.smtpserver': 'localhost:25',
>> + 'stgit.smtpserver': '/usr/sbin/sendmail -t -i',
>
> Hmm. I think it's actually more common to have a misconfigured (or
> insufficiently configured) sendmail program than a misconfigured mail
> daemon listening to port 25, so I'd argue that the default shouldn't
> be changed. But it's not that important.
OK, I'll leave the existing default (but I found in recent years that
major Linux distributions come with pretty sane configuration).
--
Catalin
^ permalink raw reply
* Re: perl t9700 failures?
From: Johannes Schindelin @ 2008-06-29 21:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano, Lea Wiemann
In-Reply-To: <alpine.LFD.1.10.0806291241210.27776@hp.linux-foundation.org>
Hi,
On Sun, 29 Jun 2008, Linus Torvalds wrote:
> Can't locate Test/More.pm in @INC (@INC contains: ...)
I cannot say that I am really surprised. And given that I _actively_
warned that something like this is prone to happen, I have to say that I
am actually a little pleased, too, since it shows I am not actually a
complete moron having warned, even if people laughed in my face because of
my concerns.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-06-29 21:57 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Junio C Hamano, Linus Torvalds, Git Mailinglist
In-Reply-To: <A87D312D-8B65-4D57-84AC-8FC07A27B937@ai.rug.nl>
Hi,
On Sun, 29 Jun 2008, Pieter de Bie wrote:
> On 29 jun 2008, at 22:11, Junio C Hamano wrote:
>
> > use of them from your scripts after adding output from "git
> > --exec-path" to the $PATH will still be supported in 1.6.0, but users
> > are again strongly encouraged to adjust their scripts to use "git
> > xyzzy" form, as we will stop installing "git-xyzzy" hardlinks for
> > built-in commands in later releases.
>
> I think msysgit doesn't (didn't?) install the hardlinks to conserve
> space, as Windows doesn't support hard links.
Please do not spread FUD. Where available, we install hardlinks.
And even if we did not, given that we do not yet actively support MinGW, I
think your suggestion is a bit early, to say the least.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Steffen Prohaska @ 2008-06-29 22:00 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Junio C Hamano, Linus Torvalds, Git Mailinglist
In-Reply-To: <A87D312D-8B65-4D57-84AC-8FC07A27B937@ai.rug.nl>
On Jun 29, 2008, at 10:15 PM, Pieter de Bie wrote:
>
> On 29 jun 2008, at 22:11, Junio C Hamano wrote:
>
>> use of them from your scripts after adding
>> output from "git --exec-path" to the $PATH will still be supported
>> in
>> 1.6.0, but users are again strongly encouraged to adjust their
>> scripts to use "git xyzzy" form, as we will stop installing
>> "git-xyzzy" hardlinks for built-in commands in later releases.
>
> I think msysgit doesn't (didn't?) install the hardlinks to conserve
> space,
> as Windows doesn't support hard links. Perhaps we should mention that
> as well?
Windows does support hardlinks and msysgit uses them.
Steffen
^ 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