Is it a common practice to make one commit mixing the changes with origin codes, when forked other's repository?

[PsiACE]

ref: databendlabs/databend#3979

Hi @wangzhen11aaa , this question is about ritelinked, and I think we can open an issue at https://github.com/dataslime/ritelinked .

---

I'm glad you're interested in ritelinked. ritelinked is derived from hashlink and they share most of the code logic. The main differences are these:

• some new features, such as amortized, support no_std
• better maintenance and well organization (eg. ritelinked's serde module was fixed earlier than hashlink)
• some functions such as get_refresh, retain

see old commit history: https://github.com/dataslime/ritelinked/commits/ritelabs/ritelinked

Also, it is a fact that ritelinked is pretty much my personal hashlink fork, although it is used by some projects. Since I plan to do some rewrites, I overwrite the commit records under the main branch, sorry for the confusion.

[PsiACE]

I admit there are some problems here, such as @kyren and others' commits being ignored, and I simply pointed out in the readme that this is a fork of hashlink. I'm sorry I didn't take care of their feelings at the time, maybe I should have kept their names in the program.

I have tried to send these changes back upstream and turn off ritelinked, but have not gotten feedback. kyren/hashlink#9

For the time being, I might consider keeping ritelinked and spending more time rewriting it to be a competitor to hashlink.

[PsiACE]

So back to the question, I don't think the behavior of ritelinked is a common practice.

[wangzhen11aaa]

That's Excellent