Re: [Gnu-arch-users] Default version for star-merge

[James Blackwell]

>     > From: address@hidden (James Blackwell)
>     > I very recently taught a friend how to use arch. A day later, he came 
> back
>     > to me and essentially asked: Since star-merge is commonly used to merge
>     > changes from the version you originally tagged from, why not make
>     > the default version to star-merge the version you tagged from.
>

Tom Lord:
> It's an interesting idea but I worry that it will lead to mistakes.

To be honest, I'm worried about the same thing, but I couldn't come up
with a strong enough devils-advocate argument to belie the thought.
Basically, for the idea to be wrong, one has to come up with a rationale
in which star-merging from the upstream could be wrong. I couldn't come
up with one.

Tom Lord:
> Roughly speaking, only _half_ of the uses of star-merge are from the
> branched-from version.  The other half are from a version branched
> from yours.  In other words, half are of a parent into a child branch;
> the other half are of a child into its parent branch.

That was my initial reaction, but after thinking about it a little
longer, I came to a different conclusion. 

Here's why. Imagine a star topology defined as A->[B, C, D, E, F], which
average five related branches* each (which works out to 25 branches*).

Every time that A does a few patches, B,C,D,E,F runs star-merge five
times each, leading to 25 star merges. And that's just the people you
know about! What about the other 500 people that are just using arch to
maintain a localized fork of the software?

However, A isn't in the same boat. The chances that A is going to
reciprocate by star-merging those 25 branches* is not nearly as likely.
Sure, A will star-merge some well trusted branches*, but many of the
other branches will be either outright ignored or cherry picked.



* Technically, "versions" is the right word here, but I think more
  people will understand what I mean if I intentionaly mispeak and say
  branches.

Tom Lord:
> Wouldn't habituating user's to omit the parameter for half of those
> cases inevitably cause mistakes where a merge-from-child was intended
> but a merge-from-parent occured?  In a tree of branches of depth
> greater than 1, that kind of mistake, especially if not noticed right
> away, could be a real mess.

As I mentioned above, I couldn't come up with a reasonable example of a
"real mess". And yeah, if somebody did come up with a plausible 

I don't think that's generally a problem in this particular case. I
think that when we're dealing with parent/child trees we're also dealing
with a mentoring relationship between the center of the star and its
spokes. The guy at the center of the star is generally going to be more
conversant with arch (ex. they have dealt with getting a project
started, they're making their archive publically available, etc)

People on the spokes are generally living much simpler lives. At the
beginning, they're doing simple little fixes (fixing typos and
paper-bag of shame type problems). They're likely not merging from
multiple directions at once, so as to remain as close to official as
they can get. Nor are they likely to be running multi-level branches! 

Sure, as time passes, their competence with development in
general and arch in specific will grow, and they'll start doing things
like that. But by that point, they're already well beyond being confused
by a default argument. 

You're referring to what I call a multi-level star: 

       A ->
            B -> G,
            C -> E, F, H
            D -> F, I

                        F
                       /
                      D
                     / \
                    /   I
                  *A*
              F   / \
               \ /   \
                C     B
               / \     \
              H   E     G


What you're saying is 'What if C meant to star-merge his H subbranch,
but forgot to specify the H subbranch and star-merged the default A
parent branch'

Well, one of two things. The user says whoops and says "Look, there's
new stuff in A anyways, so I'll commit it anyways" or "I didn't mean to
star-merge this way (at least not yet), so I'll undo this"

Tom Lord:
> (The current default for FROM, to use the tree-version, is an odd
> choice in some sense.  It optimizes a non-common-case of the command.
> But it makes more sense when you realize that, as a default that might
> happen accidentally, it is at least far more likely to be a harmless
> mistake.)
 
Aye, the current default is "safe". In the scheme of things, his idea
is really just the mother of convienances. And yes, I know that there's
important things that merit discussion.

In the scheme of things, this isn't a significant issue. There
really are more important things to worry about, but told him it sounded
like a good idea and I'd bring it up. 

To be honest, its not even that useful in lowering the learning curve
(after all, they've already reached a point where their bumping into
their own patches from upstream)... but I'm lazy, and if I can save
myself from typing in a fully qualified archive name 1/2 of the time,
I'll take it!

Failing all of the above, how about "star-merge --parent" ? 

-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400