Add history

[christianbundy]

Some commits from the v7 branch have been published, and so I think it's
wise to include them in the history of 'main' rather than maintaining
two branches. This merge commit pulls in all changes from 'main' and
then discards any local changes in the branch, which gives us the branch
history without overwriting any files.

In the future we'll be able to integrate the code from this branch
without losing any of the git blame provenance metadata, or we can
just leave the commits in our Git log as historical artifacts.

[staltz]

Maybe my understanding of git is limited here, but I don't understand this PR. Why weren't these commits in the master branch before? How come there are no files changed, and why can't this be rebased due to conflicts? I'm very confused

[christianbundy]

I don't blame you, this repo setup was super confusing. Thanks for asking good questions, hopefully I can add helpful info.

Why weren't these commits in the master branch before?

I don't know the history very well, but my understanding is basically:

• Version 6 was stable in 'master'.
• Dominic made large changes to the module and pushed version 7 to 'master' and NPM.
• Dominic found problems in the new code.
• At some point the default branch on GitHub was changed from 'master' to 'v6', which excluded the version 7 rewrite.
• Development on version 7 continued in the branches 'master' and 'v7'.

Since version 7 was published to NPM I think we should include it in our default branch, at least for historical context.

How come there are no files changed

I've merged the branches, but in the merge commit I've just used the tree from the stable 'main' branch so that there are no files changed. This means that we can merge in the historical branches without actually changing the files or breaking git blame output in the file history. If anyone wants to continue where Dominic left off (or audit the published code) then we have the relevant commits in our history without keeping a bunch of outdated branches around.

why can't this be rebased due to conflicts

I haven't tried this, but I'm guessing it's because the commits from 'master' and 'v7' have tons of conflicts since it's a complete rewrite. My merge commits neutralize the diff, and if you try to rebase then you have to handle the conflicts manually. (I'd strongly prefer to keep the actual history with a merge commit rather than rebase / squash anyway. I don't know how often you git bisect, but merge commits are one of my favorite inventions.)

[arj03]

👀

[christianbundy]

Anyone have thoughts on this patch? My inclination is to keep everything we've published in 'main' (e.g. the v7 branch), and I don't really want to throw Dominic's work away, but I won't lose sleep if this isn't something we want to merge.

[dominictarr]

v7 was a total rewrite with the goal of adding back pressure. It didn't quite work out, which is to say it's wasn't finished. I'd say v7 is probably much better code though, I think you could run v7 with back pressure disabled and it should have the same functionality as v6.

(but different interfaces. iirc I got the ssb-server tests passing with v7, but abandoned some of the muxrpc tests)

[dominictarr]

btw, thoughts on how you could correctly implement back pressure in this issue: #61

[soapdog]

Looks good to me because as far as I understand it is just record keeping, the published module still going to be 6.x.

This git manipulation is a bit above my normal usage and I think more people might want to give a bit of input before we press the merge button. I think it is OK so why not give it a day or two so that other people in the thread might voice any opinion before we merge.

[arj03]

It seems to me that this just adds the commits to the history and doesn't create a v7 branch. I think it would be interesting to have a v7 branch if for nothing else to see exactly what the changes are and maybe do some experiments based on what Dominic wrote. I know people are not fans of stale branches, but in this case I could actually use such a branch, if only temporarily.

[staltz]

I agree with @arj03 and I think it would be useful to mention v7 branch in the readme too.

[christianbundy]

I'd approve a PR to mention the previous v7 branch in the documentation and link to the commits. You should be able to git checkout and make a branch locally.

---

EDIT: I have an idea to make this easier to inspect. One sec!

[christianbundy]

Okay, I think this is slightly better -- this now puts 'v7' in our history so that we can reference it or use it later. Should be good to go now. 🚀

[arj03]

Just for future reference, how would I see the v7 changes after this is merged?

[christianbundy]

Since we aren't changing any commit IDs, this link will always work: https://github.com/ssb-js/muxrpc/tree/a9b0aeeadf6a186f7ed801a3c8bfdeac175e0971

Or git show a9b0aeeadf6a186f7ed801a3c8bfdeac175e0971 is fine too.

If you want to overwrite all the files in your working directory with the v7 files:

git checkout a9b0aeeadf6a186f7ed801a3c8bfdeac175e0971 -- .

[arj03]

Thanks :-)

[soapdog]

I think we're all OK with keeping history. Merging this one.

[soapdog]

(PS: I'm trying to work fast reviewing and merging stuff when it looks good, this is how it is supposed to go right? am I doing the maintainer thing right? I am new to these more structured processess)

[christianbundy]

Thanks for the merge!

am I doing the maintainer thing right?

Looking good to me. ❤️ 🚀