Re: [RFD] making separate-remote layout easier to use

From: Jon Loeliger <jdl@freescale.com>
Date: Nov 30, 2006, 18:16 UTC
Message-ID: <1164910560.4724.117.camel@cashmere.sps.mot.com>
In-Reply-To: <7vvel2yi2u.fsf@assigned-by-dhcp.cox.net>

On Sat, 2006-11-25 at 21:58, Junio C Hamano wrote:

Show 22 quoted lines

> Shawn Pearce <spearce@spearce.org> writes:
> 
> > Needing to put + in front of a refspec (or needing to fetch it with
> > --force) is the user agreeing that something _evil_ is going on with
> > the upstream and that they acknowledge this may cause problems for
> > them locally.
> >
> > I would prefer to see the upstream be able to publish a short
> > description of each branch, where the repository owner can describe
> > the policy of that branch, as well as have a machine readable
> > setting on each branch indicating if that branch will be rewound
> > from time to time, or never rewound.
> >
> > git-clone should skip rewinding branches by default, unless the user
> > adds an option (e.g. --include-rewinding-branches).  This way new
> > users to git.git don't get the `pu` branch unless they really mean
> > to get it, at which point they have hopefully also read the upstream's
> > description of the `pu` branch and its rewinding policy, and can
> > at least start to grasp what is going to happen if they start to
> > work with the branch.
> 
> I like this approach very much.

I see how it is! :-) When Shawn says it, it is to be liked. But when I allude to it a _year_ ago, I'm ignored.

    From: Jon Loeliger <jdl@freescale.com>
    To: git@vger.kernel.org
    Subject: Re: Trying to Update All Heads of a Repository
    Date: Fri, 4 Nov 2005 07:49:40 -0700 
    Message-ID:  <E1EY2su-0006LW-IN@jdl.com>

    So, from the git-pull man page:

        For "git push", the local ref that matches <src> is
        used to fast forward the remote ref that matches
        <dst>. If the optional plus + is used, the remote
        ref is updated even if it does not result in a fast
        forward update.

    Ah-ha!  Wait.  But here's the conceptual missing piece:
    When might I _know_ I have the situation where a
    fast-forward update might not happen?  And as a remote
    puller, that would be "never" -- unless I know something
    about the nature of the remote end.  That is, like you
    said, "pu" is subject to wild fluctuation and non-linear
    behavior.  But any random puller can't know that a
    priori.  So far, that is out-of-band information about a
    branch that needs to be "available".

Yep, out-of-band information that needs to be available indeed...

Ah well. :-)

jdl