this post was submitted on 23 Jun 2023
6 points (100.0% liked)

Programming

13362 readers
1 users here now

All things programming and coding related. Subcommunity of Technology.


This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 1 year ago
MODERATORS
 

Hey everyone, so I wrote this post a short time ago, and now I have another question regarding the same repository. I would like to remove the themes that I haven't touched as I don't want to have to deal with maintaining them every time there is a Lemmy update. Is that something I am allowed to do? Is it considered a crappy thing to do to the other dev?

Thanks in advance for all your help!

top 13 comments
sorted by: hot top controversial new old
[–] prof@beehaw.org 5 points 1 year ago (1 children)

A fork is effectively your own repo, so you can do with that as you please. Afaik MIT license doesn't hinder you from removing anything.

[–] promitheas@iusearchlinux.fyi 3 points 1 year ago (1 children)

That makes sense, just wanted to make sure there wasnt some weird condition

[–] TheTrueLinuxDev@beehaw.org 2 points 1 year ago

Yeah, MIT license is absurdly free and flexible, so basically you just need to retain copyright notice and license copy.

[–] qwen@lemmy.blahaj.zone 2 points 1 year ago (1 children)

If the themes change in the upstream, I think you'll still end up with "both modified" type conflict, "modified by them and deleted by us".

[–] promitheas@iusearchlinux.fyi 2 points 1 year ago (2 children)

Wouldnt that only happen if I try to make a pull request back to the original repo?

[–] qwen@lemmy.blahaj.zone 4 points 1 year ago

No, that will happen whenever you pull in the changes from them. You basically do a merge of their branch into your branch, which is really similar to making a PR to them (in the former case you integrate their changes into your repo, in the latter it's vice versa). In both cases Git will observe two conflicting sets of changes (one branch modified what another branch removed)

[–] hallettj@beehaw.org 2 points 1 year ago (1 children)

You'll get conflicts if you pull changes from the original repo any time the deleted files have upstream changes. After you record a merge resolution (presumably by deleting them again) you won't get conflicts until the next time those files change upstream.

If you submit a pull request part of its changes will be deleting the files from the original repo.

OTOH if you delete the files you can always undo that later with git restore --source upstream/main <deleted file paths>. You can restore them in a branch only if you do want to submit a pull request, but leave the files deleted in your own main branch.

[–] promitheas@iusearchlinux.fyi 2 points 1 year ago (1 children)

OK I think I get it now. Is there any way to "unlink" my repo from the original repo while still giving credit so I don't need to create a complete copy and go through all the setup?

[–] asden@lemmy.one 2 points 1 year ago (1 children)

The concern they raised only matters if you plan to pull updates from the repo you're forking.

[–] promitheas@iusearchlinux.fyi 1 points 1 year ago (1 children)

No i don't plan on it. Does that mean im covered

[–] hallettj@beehaw.org 1 points 1 year ago* (last edited 1 year ago)

Yes, if you don't plan to pull updates then you're covered

[–] TootSweet@latte.isnot.coffee 0 points 1 year ago (1 children)

So, if you remove those files you're considering removing, will you have completely ship-of-thesiused everything in 2xx04's repo from your repo?

Either way, just my $0.02, maybe it makes sense to just start a whole new repo. If you do need something from 2xx04's repo (like his fork of Bootstrap, maybe?), I'd say copy it into your repo and make sure the README.md links to 2xx04's repo and describes specifically what you copied and what's 2xx04's.

[–] promitheas@iusearchlinux.fyi 1 points 1 year ago

Making another repo is not something i feel like doing rn. Id prefer to leave the older themes in there and just not maintain them

load more comments
view more: next ›