Re: [Gnu-arch-users] recent changes in address@hidden, and star-merge and update/replay defaults

[Tom Lord]

    > From: Colin Walters <address@hidden>

    > On Sun, 2003-11-09 at 00:35, Robert Collins wrote:

    [a scenario where your most recent continuation ancestor is not
     the base-0 of your tree]
    
    > I personally think that's a hack, but whatever.  Note that the
    > reference version would be exactly the same, so it doesn't make
    > any difference whether you use base-0 or the last continuation.

Suppose that I cycle my archive.  Should that force you to create a
new branch?  If you don't, the base-0 default is going to do the wrong
thing.

Suppose I seal 1.1 and start on 1.2.  In my 1.2 tree, the default is
again going to do the wrong thing (since my tree is a hub, it
shouldn't even have a default and if I call star-merge without
specifying the FROM revision, I really want a usage message and error
exit, not a bogus merge).

The fix I suggested of tracing ancestry rather than just looking at
base-0 gets both of those cases wrong too: the fix would get closer to
your intended semantic but it's still a bogus semantic.

There's also a subtle design principle at work:

Heretofore, merging commands in arch are sensative to history and tree
version but insensative to tree ancestry.  That's a feature: you can
"get a tree into the source and history state you want" by any means
you like (resulting in arbitrary ancestry) -- and then use that tree
in any patch flow that makes sense.  The proposed star-merge default
would change that by making merging not merely history-sensative, but
ancestry-sensative.

There has been occaisional talk about adding new support for merge
commands and options which are, explicitly, ancestry sensative.
Although the need for them has not yet appeared obviously compelling,
in theory, they could do some interesting things.   But even so,
that's always been in the context of new merge commands and options:
not changes that make the existing ones ancestry-sensative.

Next, even if you're focused on star-topology patch flow, there are
two points to keep in mind:

1) Hub maintainers don't have a single default upstream:  they have a 
   set of upstreams.   It might be swell to have a UI that let's them
   abbreviate which one they're talking about but the point is that
   there's more than one (so there shouldn't be a single default).

2) We've talked about the alternative of {arch}/=upstream.   It may,
   indeed, be good to make upstream annotations somewhere, but 
   it's problematic to make them part of the source in a project tree:  
   do I really want changes I make to my upstream settings to appear
   in changesets that you'll be merging?

Finally: what would be so bad about starting off by publishing some
project-specific scripts for rhythmbox?   It's quite sensible to want
to make it easier for newbies to grab trees or become contributors and
scripts would do that pretty well.   If experience then shows that the
scripts are a win, perhaps other projects will take and maybe adapt
them.  If experience then shows some objectively common needs, those
scripts are one good place to start `overarch'.

-t