711–720 of 785 posts
Earlier quoted context omitted.
> Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else. I'm not a git expert but I cant image that's true
It’s not you just need to force push or generate a new key…
Earlier quoted context omitted.
I don't know if you wanted to imply that, but just to make sure no one misunderstands: GitHub didn't invent git. I don't know if they were the first git forge, but they were certainly among the first.
Yeah I know that they didn't. Even though they didn't invent it and don't own it, it's still the cornerstone of the wall that has become the Github empire. The specific problem is that all the competitors to Github have to use git, and that limits how different they can really be than Github and thus how aggressively they can compete to win users
Problem for whom? Users who are happy using git? Or conartist86 who is thinking about how to get money?
> the competitors to Github have to use git
Why? Syncing between various VCSes has been a thing since forever. If you can't handle a compatibility layer to support git+new-better-thing, you don't have the technical chops to build new-better-thing in the first place.
Earlier quoted context omitted.
I don't know if you wanted to imply that, but just to make sure no one misunderstands: GitHub didn't invent git. I don't know if they were the first git forge, but they were certainly among the first.
Yeah I know that they didn't. Even though they didn't invent it and don't own it, it's still the cornerstone of the wall that has become the Github empire. The specific problem is that all the competitors to Github have to use git, and that limits how different they can really be than Github and thus how aggressively they can compete to win users
buthub has a nice ring to it
Earlier quoted context omitted.
> You can just mess around and make it presentable later, which Git never really let you do nicely. I'm surprised to read that, because that's how I've always used Git (and GitHub). That's what I've understood to be good practice with Git, and it was liberating compared with what came before. One of the nicest things about Git is you can throw things in locally without worrying about how it looks, and make it present…
I also did that with git, but it's no comparison in ergonomics. For instance, "move this hunk two commits up" is a task that makes many git users sweat. With jj it's barely something that registers as a task.
Earlier quoted context omitted.
I would argue it being proprietary would be completely unacceptable, for such a position of importance. In any case, Git has become tremendously entrenched over the past couple decades. Anything that hopes to replace it would have to be significantly better to break from the inertia Git has. I’m honestly skeptical as to whether this is even possible in the near future. We’re not at all in the same historical moment a…
JJ has a good chance, because it builds on top of git, not replacing it abruptly.
Earlier quoted context omitted.
It’s not solved because it’s trash. There’s no good interface for it and people find it difficult to use.
Skill issue. It's the most popular VCS in the world by a huge margin, millions of devs use it every day just fine, countless forges have been built around it, and there's only one semi-compelling alternative frontend (jj). If you honestly find Git challenging, how are you coping with software engineering? Git is the easy part.