From: Jonathan Nieder <jrnieder@gmail.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
Dun Peal <dunpealer@gmail.com>, Git ML <git@vger.kernel.org>,
Stefan Naewe <stefan.naewe@atlas-elektronik.com>,
Carl Worth <cworth@cworth.org>, Jeff King <peff@peff.net>
Subject: Re: Scripted clone generating an incomplete, unusable .git/config
Date: Thu, 11 Nov 2010 12:48:29 -0600 [thread overview]
Message-ID: <20101111184829.GG16972@burratino> (raw)
In-Reply-To: <alpine.LNX.2.00.1011111241360.14365@iabervon.org>
On Thu, Nov 11, 2010 at 12:55:48PM -0500, Daniel Barkalow wrote:
> On Thu, 11 Nov 2010, Jonathan Nieder wrote:
>> --- a/builtin/clone.c
>> +++ b/builtin/clone.c
>> @@ -667,6 +667,5 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>> strbuf_release(&branch_top);
>> strbuf_release(&key);
>> strbuf_release(&value);
>> - junk_pid = 0;
>> return err;
>> }
>
> I believe that would cause it to remove the repository when it terminates,
> regardless of whether it completed or not.
Ah, right, the second remove_junk() call is because of atexit().
So why does git clone keep running after the first remove_junk() call?
It seems that the signal is initially set up (by Python's popen()?) as
SIG_IGN. I guess "git clone" should explicitly override that to be
SIG_DFL?
Here's a proof of concept. It is not very good because it overrides
any previously set sigchain handlers (in case the "git" wrappers
start to use one) and because using SIG_DFL as a sigchain_fun feels
like violating an abstraction.
diff --git a/builtin/clone.c b/builtin/clone.c
index 19ed640..2f21a91 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -458,6 +458,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
}
junk_git_dir = git_dir;
atexit(remove_junk);
+ sigchain_push_common(SIG_DFL);
sigchain_push_common(remove_junk_on_signal);
setenv(CONFIG_ENVIRONMENT, mkpath("%s/config", git_dir), 1);
next prev parent reply other threads:[~2010-11-11 18:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-10 23:21 Scripted clone generating an incomplete, unusable .git/config Dun Peal
2010-11-11 7:55 ` Stefan Naewe
2010-11-11 8:00 ` Stefan Naewe
2010-11-11 10:37 ` Jonathan Nieder
2010-11-11 12:16 ` Nguyen Thai Ngoc Duy
2010-11-11 17:32 ` Jonathan Nieder
2010-11-11 17:55 ` Daniel Barkalow
2010-11-11 18:48 ` Jonathan Nieder [this message]
2010-11-11 19:05 ` Jeff King
2010-11-12 2:16 ` Jonathan Nieder
2010-11-12 4:24 ` Jeff King
2010-11-12 4:35 ` Jonathan Nieder
2010-11-12 4:32 ` Jonathan Nieder
2010-11-12 4:41 ` Jeff King
2010-11-12 5:18 ` Jonathan Nieder
2010-11-12 5:12 ` [RFC/PATCH] daemon, tag, verify-tag: do not pass ignored signals to child (Re: Scripted clone generating an incomplete, unusable .git/config) Jonathan Nieder
2010-11-11 17:39 ` Scripted clone generating an incomplete, unusable .git/config Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101111184829.GG16972@burratino \
--to=jrnieder@gmail.com \
--cc=barkalow@iabervon.org \
--cc=cworth@cworth.org \
--cc=dunpealer@gmail.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=stefan.naewe@atlas-elektronik.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.