this post was submitted on 04 Dec 2024
176 points (91.9% liked)
Open Source
31698 readers
374 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Same, really love the idea of backing history with a proper database, and the immutability. git rebasing was a mistake.
Rebasing is for advanced git users who knows what he's doing. If one does not know how to use it or not feeling comfortable in general, he can happily take his own code and try to merge it into the latest version instead. No one is judging.
For the rest of the world where projects are open-source, more often than not, not those projects inside a corporation where only the team lead is making decisions, it's a powerful tool to settle down conflicts sort out history.
One does not need to change the history again, if he's not comfortable with it. Just use git as if it's centralised VCS like SVN. No big deal. In fact, in corporations you do. There only needs to be one person who manages the repository.
I get why it exists, but yeah it's more trouble than it's worth in most cases.
How do you cleanly base your local changes against a new upstream version? Merges?
You merge from them. If you're working on a PR, they can always squash merge your commits if you have a lot of them. No history rewriting required.