this post was submitted on 04 Dec 2024
176 points (91.9% liked)
Open Source
31654 readers
100 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
Git can be used that way too. Am I missing something?
No, you are not. People regularly equate Git and GitHub, though.
no, this is exactly what git does
So GIT has a ticketting system, a Wiki, Bug-tracker built-into it along with a Version-tracker
It also has a Sync All command (I'm sure Git also has it Somewhere) ??
Why should git have a mediocre ticketing system instead of getting out of the way of dedicated ticketing systems?
Small personal projects just need a text file with a Todo list, large organisations might need something super heavy weight like Jira. If your VCS has a ticketing system it's going to be dead weight for a large chunk of users, because there's no one-size fits all solution.
Why shouldn't git have one ? Why not avoid the bloat & Fossil was specifically made for get this small-medium size teams which can be scaled to bigger ones
I don't think you understand what the word bloat means.
git add todo.md
Now do that without the markdown file
git add todo.txt
Now do that without a text file
git add todo.txt.gz
This is funny, NGL
Darcs came out in 2003—Git in 2005. It was novel at the time compared to the alternatives. Darcs started as alternative to CSV & Subversion, not Git. Unlike Git it works on patches, not snapshots which has advantanges in merge conflicts.
Git uses ~~mergetools~~, which do whatever you make them to. Patches can be created from snapshots, but snapshots are not guaranteed to be creatable from patches - you might not have original state.
EDIT: it uses merge drivers.
Patch Theory operates under the premise that patches commute & order should not matter until there is a conflict. Git will throw fits if you pull in a patch at the wrong order giving you a different snapshot.
Specific merge tool can throw fits. Git doesn't care about specifics of how merge operation is done, it just tells to merge driver to merge three files(A, B and common ancestor) and stops if driver reports an error.
Also to correct myself: merge driver, not mergetool.
No and, in fact, this was (and still is) a selling point of Git over the alternatives (e.g. Subversion) available at the time that required you to "check out" some code and no one else could check out/modify that code while you had it checked out.