5 ms·

I used darcs before git and it was very nice - the first distributed RCS I'd ever used. I believe pijul is a follow-on to that so it should be great. Later on

• Zambyte 3y ago
  > Even I have to use git because who uses anything else? Git compatibility is a great way around this problem. I have been enjoying Jujutsu lately.
  • adastra22 3y ago
    Not really. The real innovation of a lot of these alternative DVCS systems is that they free the state of the source from being dependent on the history that got you there. Such that applying patches A & B in that order is the same as applying B' & A' -- it results in the same tree. Git, on the other hand, hashes the actual list of changes to the state identifier, which is why rebasing results in a different git hash id. So long as you require git compatibility, you're kinda stuck with git's view of what history looks like. Which is rather the point.
    • Zambyte 3y ago
      Jujutsu uses change IDs, which are an abstraction over commit IDs, that are stable over operations like rebasing.
    • sunshowers 3y ago
      That is definitely a tradeoff. On the other hand, the history of all human progress is a history of path dependence. Constraints spur creativity and Jujutsu works extremely well. (I've worked with the main author of Jujutsu before. Also, having worked on Mercurial for many years, I have my biases about how source control should work. Jujutsu's workflow is very similar to Mercurial's, with some rather stunning improvements on it.)
    • steveklabnik 3y ago
      Newbie jj convert here. jj is not patch based, like pijul, but snapshots, like git. A sibling commentor points out the change id stored by jj: it is true that at the moment, this isn't really exportable to git in a native way. However, there is a path forward here, and it may come to pass. Until then, systems like Gerrit or Phabricator work better with jj than systems like GitHub. However, all is not lost there either: tooling like spr[1] allows you to map between the two universes. At my job, at least one person was using jj for six months at work without any of the rest of us being the wiser. Some of the rest of us are trying it out. A really nice thing about jj is that you can use it without anyone else needing to, thanks to the git interop. 1: https://github.com/getcord/spr https://github.com/getcord/spr
  • toastal 3y ago
    Supporting conversion with some lossy tendencies is a good idea, but maintaining compatibility will stifle innovation as al bugs & design decisions cannot be fundamentally worked around. Adjacent, I heard folks praising Forgejo for its Actions & Microsoft GitHub compatibility, but that means you are still left with the same YAML spaghetti and its other limitations. What would have been nice is something better for CI--something that prompts the project to want to switch to get a better experience. As such, while I agree with the moral reasons to switch to non-proprietary software, the reason for switching is philosophical, not philosophical + technical. I feel being a wrapper around Git or Git compatibility will likely fall in this category rather than being more compelling.
• ccccccc1 3y ago
  but you know git and github are not the same thing right?
  • maleldil 3y ago
    For the vast majority of OSS projects, you're much better off using Git and GitHub in terms of drawing attention and attracting contributors.
• huimang 3y ago
  git != github
  • bastardoperator 3y ago
    To be fair, many git maintainers are or have been github employees and git is officially hosted on github.
    • toastal 3y ago
      That social media code forge is not the same as its underlying version control system. They are different things & we should support making folk not equate the two.
• Zigurd 3y ago
  There is empirical evidence that git is diabolical: Git can be thought of as an experiment in how to make an API GUI-proof. There is no possible direct manipulation visual representation of git operations that doesn't dumb it down.
  • ljm 3y ago
    I content that magit, while not a GUI, pretty much transcends git’s CLI. GUIs will only ever tackle a subset of git’s functionality since if you’re already a power user you’ll be comfortable with the command line.
    • Zigurd 3y ago
      I'll give magit a try. But imagine if you had to use TEX to format anything more than trivial documents. It makes me want to get a Vision Pro and see if a direct manipulation git UI could access the full potential but with visual discoverability and safety.
  • rjmunro 3y ago
    I find gitx really helpful at understanding what's going on in git. Especially its ability to drag branches around the tree shows you that branches are just labels, they aren't the actual code. It doesn't do everything, but what it does do certainly isn't dumbed down. You definitely need a gui to do partial commits. git add -P is just horrible to use.
• zemo 3y ago
  > Even I have to use git because who uses anything else? It's pretty widely not used in the games industry because its support for media files is poor, it's pretty difficult to train artists to use it, the integration with game engines is pretty poor, git LFS is a layer of complication on a system that already has UX that's difficult for artists, git LFS hosting is an additional can of worms, there's essentially no file/directory-level permissions for managing contract work (and doing so with submodules+LFS is complicated).
  • rendaw 3y ago
    Do you know of any FOSS alternatives that handle that stuff better (specifically binary asset handling and permissions)?
    • zemo 3y ago
      some indies use Subversion, but Perforce is the industry standard.
    • pmeunier 3y ago
      Pijul does binary files natively, actually. Permissions aren't hard to add, if anybody had a real-world case I'd be happy to help.
      • zemo 3y ago
        the places where I've seen people leverage the folder-level permissions in Perforce (in the games industry) would be like: a contractor that provides art would only have access to the portions of the project that relate to the art they're working on but not the code; translators might have read access on one directory and write access on another directory. In academic settings I've seen Perforce used such that an instructor has read-write access on a directory and students have read-only access on the directory, and then each student has a subdirectory where they have read-write access and everyone else has read access, so that everyone can play each other's games. You can do stuff like this in git with submodules but it's somewhat complicated and difficult to teach to non-programmers. It's not really clear what the target audience is for the project. The mathematical/theoretical foundations are clear, but the target audience is unclear, so I'm not sure if these are use-cases that you consider to be within the project's scope or not; just sharing how I've seen the permissions models used in the games industry. oh and nearly everyone hates using perforce and its clients p4v and the p4 command line, so it’s not like there’s no appetite for change. There’s very much an appetite to see Perforce unseated, because it costs money and is also bad.
• skybrian 3y ago
  There are many people who work on open source professionally, but as a hobbyist programmer I find it odd to worry about Copilot automating my “job.” This is like complaining that your dishwasher or robot vacuum cleaner automates your job because you don’t do the work by hand anymore. If you’re getting paid then it makes some sense to worry about automation, but if you’re not, automation is good. You can do more. The community can do more. We can take on more ambitious projects.
  • dbacar 3y ago
    If you are a hobbyist programmer, it is not your "job" . So it is not automating your job for the moment but the professional programmers' job, isn't it?
    • skybrian 3y ago
      Yes, what I'm trying to get across is that open source programming is often not a job. It can become a job, but I want to leave room for it being ok not to be a job.