Re: Fw: git-core: SIGSEGV during {peek,ls}-remote on HTTP remotes.
- From
Sverre Rabbelier <srabbelier@gmail.com>
- Date
- Nov 1, 2009, 14:46 UTC
- Message-ID
- <fabb9a1e0911010646v2043bdb7l9215f1114e9e8385@mail.gmail.com>
- In-Reply-To
- <7v8weq50pm.fsf@alter.siamese.dyndns.org>
Heya,
On Sun, Nov 1, 2009 at 05:27, Junio C Hamano <gitster@pobox.com> wrote:
> - Should we fix get_helper() in transport-helper.c, instead of touching > ls-remote.c like this patch does?
Probably, yes.
> This issue really boils down to this question: is it valid for a > transport to have NULL in its remote field, and should all the code > that touch transport be prepared to deal with such a transport > structure?
I think the code in transport-helper should be prepared to deal with such a field appropriately, since it knows beforehand that only a few operations will be performed on such a remote (I'm guessing just the 'list' command).
> In general, what should the initial environment for helpers be? Should > they assume that they have to figure out where the git repository is > themselves (in other words, should they assume they cannot rely on > anything the caller does before they are called?
Let's not duplicate that logic, if git can figure out where we are, it should do so, if it can't, then the helper can't either.
> Would the caller > generally have done the usual repo discovery (including chdir() to the > toplevel), and there are some set of assumptions they can make? If so > what are they?
Probably the above, if there is going to be a git repository, we'll have found it, if there isn't one, we're in 'bare' mode.
-- Cheers, Sverre Rabbelier