Re: [RFC] origin link for cherry-pick and revert

From: Stephen R. van den Berg <srb@cuci.nl>
Date: Sep 11, 2008, 23:17 UTC
Message-ID: <20080911231742.GD29559@cuci.nl>
In-Reply-To: <20080911230117.GA4194@coredump.intra.peff.net>

Jeff King wrote:

Show 6 quoted lines

>On Fri, Sep 12, 2008 at 12:56:48AM +0200, Stephen R. van den Berg wrote:
>> Well, the usual way to fix this is to actually startup fetch and tell it
>> to try and fetch all the weak links (or just fetch a single hash (the
>> offending origin link)) from upstream; this is by no means the default
>> operatingmode of fetch, but I don't see any harm in allowing to fetch
>> those if one really wants to.

>Maybe I am misremembering the details of fetching, but I believe you
>cannot fetch an arbitrary SHA-1, and that is by design. So:

I see, didn't know that.

>  1. You would have to argue the merits of changing that design. I
>     believe the rationale relates to exposing some subset of the
>     content via refs, but I have personally never felt that is very
>     compelling.

Well, I can understand why it is done this way, I think.

>  2. Even if we did make a change, that means that _both_ sides need the
>     upgraded version.

If you're using origin links, you'd need that anyway, so that's a given. I could imagine the minimum would be something like:

 Allow direct SHA1 fetches (which obviously pull in all parents as well)
 if the ref is part of one of the public branches (either as a commit,
 or as an origin link).

-- 
Sincerely,
           Stephen R. van den Berg.
"There are three types of people in the world;
 those who can count, and those who can't."