Re: what should patchy do for staging?

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Wed, Nov 09, 2011 at 09:58:56AM +0100, David Kastrup wrote:
>> [Diversion: by the way, Phil and Graham?  I have come to the conclusion
>>   that it is better if Patchy does not attempt any rebases or merges on
>>   its own.  Can you change that accordingly?  It should quite simplify
>>   Patchy and make its behavior more predictable: it would just try to
>>   push its tested version of dev/staging to master, and if that fails,
>>   it fails.
>
> I am in the middle of reinstalling OSes, setting up development
> environments, and making the 2.15.17 release.  And I do not
> understand, nor do I *care* to understand, the difference between
> rebase and merge.

Neither is something that should happen as part of an automated job.
Just fastforwards.  Fastforwards leave the structure intact, and they
leave the commits intact, and tags and everything else.  Both rebase and
merge commands do fastforwards instead of actual rebases or merges when
they can, unless explicitly told otherwise.

When they can't, they do different work.  A merge looks at the state of
both work trees and the history and creates a new work tree combining
both work trees where they are not in conflict.  It marks both revisions
as parents of the new revision.  It does not rewrite any commits.

In contrast, a rebase starts with a base, then cherry-picks all commits
in another branch that are not present in the base.  Cherry-picking more
or less is applying the commits as patches, one by one, creating new
commits and a new history in the process.  Cherry-picking a merge
commit, if any is in the new branch, is a nuisance, to put it mildly.

A rebase is more manual work than a merge, but leaves a linear history,
as if written on top of base.  When we are talking about significantly
diverged development, resolving every conflict while rewriting the
history is too much work.  It is saner to keep the separate histories
and just resolve the conflicts in the resulting trees.

Making a choice between rebase and merge depends on the respective
sanity of the situations.  So when a fastforward is not possible, and a
choice has to be made, I prefer that a human does it, by doing the
appropriate rebase or merge on dev/staging, and after that, the
automated process can fast-forward again.

> Run this command:
>   git clone git://github.com/gperciva/lilypond-extra.git
>
> and then edit the
>   patches/compile_lilypond_test.py
>
> I think you are interested in the
>     def merge_staging(self):
> and
>     def merge_push(self)
> and maybe the
>     def staging()


> If anybody else is reading this, and knows (or cares) about git,
> and knows (or cares) about setting up an automatic tool to make
> our lives easier, you could follow the same instructions.

I'll take a look.

>> Maybe we should rename the staging branch into just
>>   "staging" as the "dev/" is needlessly obscure. ]
>
> sure, that's fine with me.

Eventually.

Sorry to be a pest.  I am currently queuing up half a dozen of other
issues/patches, and will likely need several releases to get the
respective conversions done in reasonable proximity to their changes.

-- 
David Kastrup