Re: [Gnu-arch-users] Re: --skip-present implemented

[Tom Lord]

    > From: Miles Bader <address@hidden>

    > Hah, hah, I just tried my tla with your --skip-present patch, and it
    > does _exactly_ the right thing for me...!

Well, sort of -- mostly.  And yes, modulo fixing minor issues that may
or may not show up when I review, it I'll merge this.  But:

    > I do `pure merges' from my auxilarly branches to my main branch, 

That's the only caveat.   You _say_ you do pure merges -- and you
probably do -- but you'll have to maintain a discipline to be sure
that that's _really_ what you do.

The "danger scenario" here is that you set out to do a pure merge into
your main branch.   You do the merge and, let's say that the
build/test reveals a minor unrelated bug or you notice some unrelated
bug while fixing a merge conflict.   Without thinking about it, you
fix that one-line bug, then commit (along with the merge itself).

Now your pure merge isn't pure because it contains changes other than
the merge.  If using --skip-present causes the impure patch that
includes that bug-fix to be skipped, the bug fix is dropped.

The original plan (like, early 2002) was to try to make some commands
for idempotent merging that wouldn't let you make such mistakes.  The
serious problem with the original plan is nobody could think of how
such commands might work on systems that don't have the system call
`perform_magic()' (which I think was scheduled to be added to the
Tahoe BSD release but was dropped as part of the settlement with AT&T.
SCO may have aquired the code for it and if it turns out that XFS is
using `perform_magic()' internally -- that's probably the _real_ basis
for their suit).

The good news is that Rob (starting with larch) plowed ahead with
variations on his approximation of perfect idempotent merges and, even
though I tried to maximize the amount of theory-based skepticism I
exuded about it, he's found it quite useful in practice.  (I think
some other people have as well and now you, too.)

So, I'll merge this yes: but also when there's a tutorial chapter on
"The pure-merge Style of Cooperation" perhaps it should take some time
to warn about the danger scenario described above.



    > and
    > then later want to just do a normal merge from the main branch to the
    > aux branches, but star-merge always gets completely confused by the
    > previous pure merges (and of course replay just gets conflicts).
    > Now I can just do replay --skip-present to do the main->aux merges!

And if you toss in some appropriate sync-trees, there, or if the
merges thus performed happens to give you the latest patch-logs in
main and in the branches, then star-merge will be happy again.

In other words, if for some project the "cost of maintaining pure
merge discipline" is an issue and star-merge is preferred when it
applies, you can pretty easily go back and forth between modes where
star-merge is doing the right thing and where --skip-present is
letting you "bend the patch-flow rules" when you have to.

(For something like your private Emacs branches, you having a clue
what you're doing when you use arch, the cost of maintaining pure
merge discipline is presumably quite low and recovery in cases where
you realize you've screwed up quite trivial.  I think that _that's_ the
core of the practical fact that trumped my in-theory skepticism.)


-t