I kind of get where they are coming from. However git seems so ubiquitous that few people even consider possible alternatives.

What are your thoughts on this?

  • poVoq@lemmy.mlOP
    3·
    3 years ago

    What you write makes sense for bringing in new inexperienced people on highly complex projects, but I wonder about more simple stuff (like a ansible / docker file or a website etc) that would benefit from a repository and might have several occasional (but basically trusted) contributors. I think many people shy away from using git for that because the entire process becomes really bureocratic unless you allow people to push directly to main, which is not all that desirable if there is for example a CI process automatically building the website out of that.

    For something like that the autosync workflow of fossil-scm seems more suitable, no?

    • D. Moonfire@lemmy.ml
      2·
      3 years ago

      “All projects start simple.”

      Actually, for trusted teams, I would have just everyone push to master. If you don’t need gatekeeping, then go direct to master. Branches in a Dockerfile repo? Probably doesn’t need it.

      Now, autosync. I have wasted so much time in my life on triggers, things that work automatically in the background. On paper, it seems like a great idea, and they usually are as long as they work perfectly. But, the automatic nature also makes it hard when it fails part of the way in. This includes the fixture setups of NUnit, database triggers, and everything else.

      It also depends on how people work. I use task branches because I frequently commit broken code on my local branch because I’m at a stopping point, I need to look at something else, I need to switch branches, or simple just feel that it is time to commit and push. As I said earlier, that happens about every five minutes or so when I’m in the groove.

      Having autosync in the middle of that causes problems for me because I have an environment set up correctly and really didn’t need Bob’s database change in the middle of my work, or Bob has trouble because I won’t stop committing changes when I’m in the “knock out all the small items” mode. In those cases, I found it more disruptive when things just “magically work” just happen to magically break code before and after lunch. It gets really bad when someone changes a NPM or NuGet dependency since those aren’t always picked up automatically when you hit Run.

      I like that merge to be explicit because I can say “I’m ready now” and make work on those changes instead of interrupting my train of thought and having to go through a context switch.

      That all said, James White had a wonderful short story about how everyone works different. Larry Wall’s “there is more than one way to do it”. Not everyone has those limitations or encounters them. I have, so I avoid situations where I know it will be a problem. I also don’t handle context switching that well :P and like to know one set of tools well. Since I live in Git for so much of my life (writing, household, accounting, work), that is my tool of choice. Would I contribute to a project that doesn’t use Git? Well… probably not. Same as I don’t contribute to Go, Ruby, and Python projects. It isn’t for me.

      But for others, it may be. I think that’s great. Work with the tools you want and the ones that work the way you want to work.

      I just have experienced so many times when those major points selling points of Fossil have caused me problems. I know how I work and how I think, so I’m pretty sure I’ll encounter those same things and be just as frustrated. As it happens, Git works like I think, so it fits me better.