Graham Percival <gra...@percival-music.ca> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
