merge vs rebase ontop of io.js about node-convergence-archive HOT 22 CLOSED

I agree. Like I said on IRC, no one likes pointless merge commits.

from node-convergence-archive.

I tried combining the two with the following merge tactics thus far:

1. Brute force merge the trees. This is a no-go, unless we get a crowd of the people involved on google hangouts.
2. Merge incrementally. Pretend as if we've been merging all along – doing 4-5 commits at a time. This will be time consuming, and also seems like a bit of a no-go.

Re: Merge commits being pointless – it comes down to whether we want to preserve the history of the v0.12/3 lines, or if we want to treat all of the changes that happened there as "new" commits. Rebasing means the commits will be duplicated (new hashes, new parents, possibly new content) into the master branch, though it does preserve linearity of history. I initially leaned towards a single merge commit to prevent the duplication – mostly because I wanted to preserve the release commits and "working on commits" in the node branch at the time.

What's being discussed on IRC is cherry-picking specific commits into a branch that's rebased on top of master. I'm generally in favor of this approach, but we get into specifics of "what commits do we merge" vs. "what commits do we skip" and it starts to get tempting to editorialize (which we've attempted to avoid doing with this repo.)

from node-convergence-archive.

but we get into specifics of "what commits do we merge" vs. "what commits do we skip

Aren't there a lot that we would objectively want to skip though? Aren't there a bunch of commits that essentially just backport io.js changes to older v8 that we're not even on now?

from node-convergence-archive.

Aren't there a lot that we would objectively want to skip though? Aren't there a bunch of commits that essentially just backport io.js changes to older v8 that we're not even on now?

Yes.

from node-convergence-archive.

While there are commits like that (I've omitted them from my list), I'm referring to commits like the openssl v2/3 switch, where the convergence plan states that "the next major version of Node will have all of the features of both io.js and node.js."

from node-convergence-archive.

the next major version of Node will have all of the features of both io.js and node.js."

In the last convergence meeting we sort of amended that though. If I remember correctly the plan was:

• Get master to a point where all feature from io.js and node.js are present.
• Open it up for people to propose changes as PRs before the first release.

This way there is a chance, prior to release, to re-consider things as a combined TSC but they have to be proposed at reversions rather than as debates on the merge commits.

from node-convergence-archive.

Do note: it is planned to be a major, so breaking changes could be done.

from node-convergence-archive.

Right, but it would still be unexpected if a feature was abruptly removed without a cycle of dep warnings. However, we have an exception in the dev policy for anything security related, which the SSL switch may quality for.

from node-convergence-archive.

@jasnell how do you feel about this?

What's being discussed on IRC is cherry-picking specific commits into a branch that's rebased on top of master. I'm generally in favor of this approach, but we get into specifics of "what commits do we merge" vs. "what commits do we skip" and it starts to get tempting to editorialize (which we've attempted to avoid doing with this repo.)

from node-convergence-archive.

Well, currently recovering from a bit of food poisoning so haven't had a
chance to catch up. But at first blush we need to avoid anything that even
has the appearance of editorializing commits. If there are things that need
to be deprecated, then those should pad through the full major release
cycle as documented in the dev policy.
On May 9, 2015 3:03 PM, "Jeremiah Senkpiel" [email protected]
wrote:

@jasnell https://github.com/jasnell how do you feel about this?

What's being discussed on IRC is cherry-picking specific commits into a
branch that's rebased on top of master. I'm generally in favor of this
approach, but we get into specifics of "what commits do we merge" vs. "what
commits do we skip" and it starts to get tempting to editorialize (which
we've attempted to avoid doing with this repo.)

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

from node-convergence-archive.

Particularly, I'm wondering about

What's being discussed on IRC is cherry-picking specific commits into a branch that's rebased on top of master.

We can cherry-pick the commits in order, but I feel by subsystem would be easier. (for conflict resolution).

I don't think "editorializing" it is bad, this way we don't need to port over merge commits and other metadata that is no longer of use.

We can take all the then-relevant commits and functionality, discussing afterwards. That is fine by me.

from node-convergence-archive.

Well, currently recovering from a bit of food poisoning so haven't had a
chance to catch up

Also, take your time to get better, no rush here, food poisoning is nasty! :)

from node-convergence-archive.

But at first blush we need to avoid anything that even has the appearance of editorializing commits.

One thing that might help here is if when we think we're done with the merge we open it up to the contributors to find anything that was missed. During that period we'd still be in the "merging phase" and anything from either project would get accepted without contest.

from node-convergence-archive.

Re: Merge commits being pointless – it comes down to whether we want to preserve the history of the v0.12/3 lines, or if we want to treat all of the changes that happened there as "new" commits.

I could live with a single merge commit but the way the forks have diverged, you'd probably end up with a merge that is 50% conflict resolution. It would be terrible to review.

from node-convergence-archive.

Here are the test branches side-by-side: master-with-merges / master-using-rebase

@jasnell if LGTY I'll start pushing the rebase one. PR's will be a little wonky to do maybe, but it'l end up the most reasonable IMO. (from a git perspective)

from node-convergence-archive.

Ok, I'm tied up at a conference now. Will look in a bit!
On May 11, 2015 7:27 PM, "Jeremiah Senkpiel" [email protected]
wrote:

Here are the test branches side-by-side: master-with-merges
https://github.com/jasnell/node.js-convergence/tree/master-with-merges
/ master-using-rebase
https://github.com/jasnell/node.js-convergence/tree/master-using-rebase

@jasnell https://github.com/jasnell if LGTY I'll start pushing the
rebase one. PR's will be a little wonky to do maybe, but it'l end up the
most reasonable IMO. (from a git perspective)

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

from node-convergence-archive.

fwiw, +1 for a rebase / cherry-pick, a lot of changes have been made to io.js (ish node.js 😀 ) and a single merge commit would hurt git blame / history

from node-convergence-archive.

Ok, quick review it LGTM!
On May 11, 2015 7:27 PM, "Jeremiah Senkpiel" [email protected]
wrote:

Here are the test branches side-by-side: master-with-merges
https://github.com/jasnell/node.js-convergence/tree/master-with-merges
/ master-using-rebase
https://github.com/jasnell/node.js-convergence/tree/master-using-rebase

@jasnell https://github.com/jasnell if LGTY I'll start pushing the
rebase one. PR's will be a little wonky to do maybe, but it'l end up the
most reasonable IMO. (from a git perspective)

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

from node-convergence-archive.

Ok pushed that to master.

Next question would be: do we want to apply the commits in entirely historical order, or group them by subsystem/something so that the process is easier? (doc: commits would definitely be easier to do separately all at once.)

from node-convergence-archive.

Don't commits build on each other? I'd think the cherry picking could get ugly if its not in historical order. Also, commits that don't conflict can still relate to each other, and doc commits sometimes come in after the code they doc (in theory, code and docs are update simultaneously... but that's just a theory). If its not in historical order, the intermediate stages might be subtly broken. Which might not matter, as long as the end result is good.

from node-convergence-archive.

Yes, if we split it out into groups we'll have to make sure we're
reconciling with the historical view as we're moving along to make sure
important bits do not get missed, it's also like that not everything will
fit into nice neat bundles. Even so, splitting it up into functional
groupings is likely going to be the most efficient as it allows us to focus
on specific areas to ensure functionality is consistent and we're not
accidentally missing larger picture impacts.

On Tue, May 12, 2015 at 9:22 PM, Sam Roberts [email protected]
wrote:

Don't commits build on each other? I'd think the cherry picking could get
ugly if its not in historical order. Also, commits that don't conflict can
still relate to each other, and doc commits sometimes come in after the
code they doc (in theory, code and docs are update simultaneously... but
that's just a theory). If its not in historical order, the intermediate
stages might be subtly broken. Which might not matter, as long as the end
result is good.

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

from node-convergence-archive.

@Fishrock123 ... any reason to keep this one open?

from node-convergence-archive.