• 0 Posts
  • 23 Comments
Joined 3 years ago
cake
Cake day: August 1st, 2023

help-circle





  • To be fair, I think those devs have a good idea on how a content-addressable-filesystem-cum-blockchain should work. The primary use-case, Linux kernel development, has very particular needs such as being distributed, allowing complex merge strategies, and being aggressively transparent. That the rest of the world then adopted this particular (D)VCS was mostly an accident.

    Back in the before times when git was first new, I was an avid supporter of svk (a perl hack that bolted on distributed qualities to svn). Very useful to have complete server state locally especially for merging. svk worked, but had a lot of foibles, being the hack that it was. When I finally pulled the trigger and migrated repos over to git, even those early versions, reduced the complexity of my setup dramatically. Haven’t looked back since. The porcelain of git has improved dramatically over the years (even if I still use git checkout -b). But it is still very much an expert tool and most users don’t engage deeply with it. Which is exactly what the blog post recognizes and laments because the supposed experts aren’t.


  • Most projects do not need the complex merging capabilities of git. I’ve found that simply structuring the workflow around trunk based development with linear history works the best: short lived feature branches that get rebased/squashed/committed and the tip of main is always deployable. It avoids dealing with all of the bullshit that comes with long-lived branches and migrating changes between them. This also requires structuring the work itself if you have a larger team so that if you are all working on the same system, avoid crossing the streams (draw some boundaries) to keep dependencies between branches at a minimum. When it starts getting into stacked patches, that’s a good sign you have a kink in the review pipeline somewhere and this complexity can go away with some managering. Git is as complex as you want it to be, and pretty easy to keep it simple






  • okwhateverdude@lemmy.worldtoLinux@lemmy.ml•RTFM
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    2
    ·
    6 months ago

    What’s worse, is if this is GNU-ware, there is a good chance the answer IS NOT IN THE MAN PAGE. I think it was bash or maybe gawk. I don’t remember exactly, but I had a question that simply wasn’t answered in each man page. GNU docs are absolute trash, written without any consideration for the audience.