Re: rebasing inside staging

[Graham Percival]

On Tue, Nov 29, 2011 at 03:41:25AM +0100, David Kastrup wrote:
> Graham Percival <address@hidden> writes:
> 
> > 2) remove that commit, then rebase origin/staging on the result.
> >
> > I'm not comfortable rewriting history on a shared repository.
> 
> I'll do the second one.  Rewriting history is easy, and that is what
> staging is for.

Excellent!

> The aftermath will be more interesting.  People
> committing to staging (and rebasing on staging) should double-check that
> they are only committing their own commits and not old commits we chose
> to back out.

... yes, "interesting times ahead" indeed.

> An interesting question is how the commit could
> a) acquire changes not at all described in the commit message

eh?  The description seems legit here.  At least, I assume that
changing \super to \normal-size-super would "enlarge
half-diminished slash circle symbol".

> b) pass testing and acquire "Push" status

1503 had a whole bunch of changes, and it was waiting for
something like 3 weeks before getting pushed.  It's possible that
that syntax worked before the recent scheme changes, or it's
possible that James wasn't testing on a completely clean build
tree and lilypond doesn't regenerate that part of the docs... come
to think of it, since the change was in a ly/ file rather than
input/, I very much doubt that the build system would notice that
dependency changing.

*shrug*

I see no reason to panic about this.  Unless we vastly ramp up the
amount of red tape, there will always be some patches that slip
through the cracks.  I think the best option is to improve the
automation; if I can reliably leave my computer compiling stuff 24
hour a day, then there's no problem recompiling absolutely
everything from scratch all the time.

Cheers,
- Graham