i think a better choice for me is to create a new fork and pick only some of the key modification (like markdown) into the new branch and drop some less important features. or the fork will be hard to maintain in the future
@freemo you are right. i thought my repo was well maintained before (i use rebase pull to merge upstream every time), but with time goes by, i need to rebase hundreds of commit every time. this time, the v4 changed too much, have spends hours on that, about to give up :(
by the way, how about your fork my friend? i see qoto still on v3.2
🇳🇱
@mashiro it can be hard maintaining a healthy history.. its more than just rebasing... you need to keep your commits tidy, small (elemental), and sometimes need to do some advanced things... also merges are better than rebase for this, rebase has its place but for long ter maintanence of a branch you want to do merges so you dont have to re-do the conflicts every time (which will just pile up), with merges you wont have to re-apply old conficts and get to focus just on the newer conflicts.
@freemo can't agree more now. i'm also considering merge all my commits into one commit now 😥
@mashiro no no, that will make it WAY worse over time... your better off just fixing it this time, then merging int he future...
@freemo yes, you are right, after all i've merged v4... but the rails can't be booted now 😥
@mashiro As someone maintaining my own fork I know the pain!
@mashiro if the fork was done in a way that uses good Git practices then by dropping those features you might make your life harder than by keeping them to be honest.