4 ms·
Well, do you use GitHub or an equivalent? The point of this, as the article states: > These additional capabilities are available for Git as 3rd-party add-ons
by maegul 3y ago
Well, do you use GitHub or an equivalent?
The point of this, as the article states:
> These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design, to the point that it approximates "GitHub-in-a-box.
I’ve not used fossil, but I appreciate this idea.
Sure, it’s not unixy, but maybe a VCS reasonably demands such features, and today, it’s not as though these are crazy advanced or complex features.
- deleted 3y ago[deleted]
- otabdeveloper4 3y agoGitea is already "GitHub in a box". Also, GitHub is not something to emulate, it is the lowest common denominator of repo hosting.
- Zababa 3y ago> Also, GitHub is not something to emulate, it is the lowest common denominator of repo hosting. What do you mean by this? Having mostly used git and github, I don't really know what I'm missing.
- bradley13 3y agoJust a minor example that irritated me today: try to look at a graph of past commits. In GitLab, it is nicely presented. In GitHub, it is nearly useless.
- toenail 3y ago> Well, do you use GitHub or an equivalent? Not sure how that's relevant, but I have ~150 repos locally and less than 10 on github. I also like the unix philosophy of having tools that do one thing and do it well.
- sausagefeet 3y ago"One thing" depends on how you squint, though. If you view "version and track text information" then it makes sense to store tickets, wiki, code, yadda under the same tool.
- toenail 3y agoI'm primarily a command line user, I don't use explorer to view, rename, move, copy files etc. Like I said, unix-y. If you think "manage computer stuffs" the OS should bundle all tools anybody could ever want.
- thfuran 3y agoMost popular Linux distros include a whole lot more than just a stripped down kernel.
- sausagefeet 3y agoAnd yet you don't use different file systems for small files vs large files, for text vs movies. One assumes that a filesystem can handle all of that kind of data. But one layer above we don't want all those under a unified interface.
- toenail 3y ago> And yet you don't use different file systems for small files vs large files, for text vs movies. Um, yes, I do. Not that it matters anyway, filesystems are not optimized to handle source code to begin with, they deal well with sectors/blocks and do that well.
- simultsop 3y agoTo me it feels like, rare and smart ones, trying to penetrate giant markets with all in one solutions. I'm not even mad. But find it hard to comprehend who would make such change. Probably they want to test their patience and expect considerable userbase in 30 years, finally monetize it.
- dartos 3y agoOr they just made a tool that solves a problem for them. This whole article is pretty much why fossil was made.
- Vinnl 3y agoTo clarify the actual benefit: this means that tickets, etc. are also distributed, i.e. available and backed up locally with every contributor, and not dependent on lock-in to a single vendor like GitHub. Edit: and yes, of course there are downsides as well. It's up to you to weigh them against each other.
- prepend 3y agoI understand, I don’t care about that.
- otp209 3y agoOkay? Some of us might want to. As the git people love parroting of its myriad kitchen sink commands, "if you don't like it you don't have to use it". I'd rather have a single integrated tool than the shopping list of "just use X and Y and Z" people are prescribing in this thread for getting the so-called git ""ecosystem"" ""working"". Not that I'll necessarily use all the added features; but the ones I do want being integrated is absolutely relevant to my interests.
- mgaunard 3y agoYeah, I really want to solve merge conflicts on tickets.
- mbivert 3y agoVersioning/distributing tickets is indeed useful; but can't this be "implemented" in git already, by defining a file-based format (think, issue/$YYYYMMDDHHMMSS-$title.md, but the variants are endless), and versioning those files? A first drawback I can think of is that this would probably require an additional layer for non-tech people. I haven't had the opportunity to use Fossil, so I am clueless regarding the kind of UI they propose, but I wouldn't be surprised that they actually solve this, considering the extensive list of features.
- hn92726819 3y agoWell the article does say: > These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design
- prepend 3y agoI like the “separation of powers” between git and GitHub functions (and gitlab). It’s nice to be able to start git repos locally and only push to GitHub when I need to. I also use gitlab quite a bit and it’s so clean to be able to pull from gitlab and push to GitHub, or vice versa. I don’t need any utilities, I don’t need any special workflows. Git is sort of like a protocol with gitlab, GitHub, and others built on top. If GitHub owned git then it would be so tightly coupled and suck. I don’t think a VCS demands features of chat and the others. And the evidence provided by the millions of users seems to support that. It’s not that chat and wiki are super complicated, it’s just more stuff. Implementing an alarm clock isn’t complicated either, should VCMs have alarm clocks as well?