feathers

joined 1 year ago
[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

You need rebase instead.

Yep yep, that's what I do for my feature branches! ;)
Or, well, at least when I'm the only one working on them, anyway~

when it comes time to PR

Oh haha, I really doubt I need to worry about that; these are pretty community-specific features, I doubt the upstream project would even want them. I am concerned only with keeping my fork's main development branch up to date with the upstream's. Y'know, after I merge my custom features into it. There seem to be a bunch of intricate ways to do it (see the blogpost I linked), and I'm unsure if I should care about any of those, or if I can get away with just,, doing a normal merge.

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago) (5 children)

Oh, no, haha, I didn't mean merging my changes into upstream! I meant merging upstream changes into my fork :p
edit: changed wording in my post so it's a bit more clear what I mean~

[–] [email protected] 1 points 1 year ago

oooh, ty! I'll check out how they do it (...whenever their repo comes back online :p)

16
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/fediverse
 

Hey, if there are any folks here involved in friendly forks of fediverse software - Do you use any fancy merge strategies to merge upstream changes into your fork? What's your mileage?

I've been hacking away at a private lil fork of Pleroma, adding some little convenience features for myself, and thought it might be a good idea to ask if I should be doing any of the fancy stuff github describes in their article about friendly fork management, or if I'll be alright just doing git merge upstream/develop :^)