Re: Fw: git-core: SIGSEGV during {peek,ls}-remote on HTTP remotes.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Heya,

On Sun, Nov 1, 2009 at 05:27, Junio C Hamano <gitster@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]