I would like to introduce you lovely OpenSource Lovers to a GIT-Alternative called FOSSIL that I also stumbled upon because of this Blog.<br> It’s basically opensource Github-in-a-box which means it’s an SCM with:

  • Bug-tracker
  • Ticketting-system
  • Forum
  • Wiki-system
  • even a Chat-functionality
  • Has built-in GUI
  • Also has a Web-Server
  • Self-Hostable like Gitea/Forgejo

& the best part it’s all in ONE STANDALONE FILE!!! which is extremely lightweight which you can copy to your $PATH & works even in crappy internet. how cool is that!!

However this tool supports a completely different style of development in FOSS called the “Cathedral-Style” whereas GIT suports a “Bazaar-Style”<br> The person behind Fossil is the creator of SQLite, <u>Dr.Richard Hipp</u> & they even made other projects to support Fossil like a PIC-Like language called PikChr<br> Well just in case; here’s a list of difference between Git vs Fossil<br> & guess what!! they even have a hosting service called CHISEL

Listen; Just check it out & use it for fun in your spare time even with the flaws it has (& Try out Darcs & Pijul as well)

    • nimpnin@sopuli.xyz
      24·
      30 days ago

      Darcs does not require a central server, and works perfectly in offline mode.

      Git can be used that way too. Am I missing something?

        • ZeroOne@lemmy.worldOP
          19·
          28 days ago

          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) ??

          • jmcs
            102·
            29 days ago

            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.

            • ZeroOne@lemmy.worldOP
              16·
              29 days ago

              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

      • toastal@lemmy.ml
        5·
        29 days ago

        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.

        • uis@lemm.ee
          2·
          28 days ago

          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.

          • toastal@lemmy.ml
            2·
            28 days ago

            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.

            • uis@lemm.ee
              1·
              28 days ago

              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.

      • PHLAK@lemmy.worldEnglish
        4·
        29 days ago

        Am I missing something?

        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.

      • 2xsaiko
        5·
        30 days ago

        Since jujutsu is Git-compatible it has very much replaced Git for me and is what I’m using for everything now. Its workflow is so good and miles ahead of Git.

        I was trying out Pijul for a while before that and while it has a lot of great ideas and has a lot of potential due to the way its foundations work its interface is way too janky right now and missing features and nothing I’ve reported or the many changes I’ve submitted have been fixed/pulled since March. I’d really like it to be good but alas…

        • el_bhm@lemm.ee
          2·
          30 days ago

          Assuming you are using feature branches with git, I have quesitons.

          1. Are you a merge or rebase guy?
          2. Squash or “let commits pile up”? These are just to understand the way you are using git.
            What is the killer feature for you over git?
          • 2xsaiko
            1·
            30 days ago
            1. Always rebase (feature branches on top of master)
            2. That depends, with Git what usually ended up happening was let commits pile up, then when I’m about to merge it to master squash them into logical units. With jj I often just squash as I go since it’s way faster than in git. Look at this branch for example, you can see exactly when I switched to jj (though this entire history is a mess which I’ll still have to untangle before merging)

            The killer feature for me is the mega-merge, which is a great workflow that is very difficult if not impossible to recreate in Git which allows you to work on many feature branches at once while keeping them independent. It’s basically a merge commit which you have checked out which has all your feature branches as a parent, and jj makes it trivial to manage this. This is usually how I want to work and with Git what ends up happening if I want to do that is I will add a new feature to an existing feature branch that doesn’t really belong there, but this obviously makes it very easy to write code which depends on the incomplete feature that came first and then becomes very hard to separate if you want to merge the second feature before the first.

            This has also essentially saved me from what I did before with Git, which is having way too many work trees (still, shoutout to git worktree here), one for each branch.

            Here’s the log from one of my repos that I use the mega-merge with right now: https://paste.gentoo.zip/JRxJDhiQ and the corresponding log on GitHub for the top branch; the log, which I’ve configured here to show the changes that are in my fork but not in the upstream fork, actually shows three main branches (master, nixos-unstable, nixos-24.11). You can see most of the 6 branches that master merges actually have a corresponding remote branch (shown between the date and the commit hash) because they have or had PRs open. Changing anything about this graph (rebasing it on top of new master@upstream, inserting a change somewhere, deleting/modifying an existing change, etc.) will rebase every dependent change, that is, the ones that have the modified one as a parent (!!!) on whatever changed and also update branch pointers, so when I push the next time, for example after a rebase, it will have updated all those branches for me and I don’t have to go through fixing each one. Especially the latter I think is not possible with Git, a rebase operation will only affect the current branch. I have no idea how Git deals with rebasing merge commits, I think I’ve tried once and it became a mess and I haven’t touched rebasing merge commits since.

            Honorable mentions include

            • conflicts do not block operation, you can resolve them whenever you want to and until then any operation will work, they will just show up with a conflict symbol in the log until you fix them
            • branchless workflow: you can just start creating changes off any commit without having to set up a branch first, and they will all show up in the log, which shows you by default all of your local changes that aren’t pushed yet, regardless of which branch (or none at all) they are on
            • revsets, a great way to select a set of changes using an expression (this was apparently stolen from Mercurial). For example, I might want to list all of the commits I made that start with “foo:”. This is easy to do with revsets: jj log -r 'mine() & description(glob:"foo:*")'.You can also use this to select a set of commits to be squashed, rebased, deleted, or whatever.
            • el_bhm@lemm.ee
              2·
              30 days ago

              Thanks so much for this. I may end up trying this out. This n-branch auto rebase sounds like a thing I may end up loving.

      • toastal@lemmy.ml
        3·
        29 days ago

        I ‘forgot’ it on purpose.

        The compatibility with Git means it is ultimately shackled to the design decisions fundamental to Git which require hacky workarounds. The maker of Pijul has pointed out some of the fundamental ways it can never handle patches is the manner of Darcs/Pijul, but I am not in the position to pull some of these quotes.

        I would rather see revolution over evolution, & the weird ties to Google & hosting the project Microsoft GitHub rub me wrong.

        • PropaGandalf@lemmy.world
          1·
          29 days ago

          but they are working on their own vcs. I think git compatibility is not much more than a convenience in the long term.

    • ZeroOne@lemmy.worldOP
      14·
      28 days ago

      Oh Yeah I like Pijul as well & I fully agree with your point of breaking the Git Hedgemony

      BTW, tell me more about Darcs I want to know EDIT: Boy GIT-Fanboys are clearly mad about other VCSs existing😅

      • toastal@lemmy.ml
        4·
        29 days ago

        Darcs is sort of like Pijul before Pijul. It is a little slower, but might not even affect you at your project size, but what it has instead is a longer history with more tooling & support—on the CLI, support from package managers, forge options. It ends up being my preferred option just for this reason even if Pijul has better performance, handles binary files, & the identity server is novel.