51–60 of 309 posts
I think Git itself is probably too entrenched to be displaced by now, but I recently came across Graphite ( https://graphite.dev/ ) and, while it’s all still Git under the hood, it abstracts away many of the common pain points (stacking PRs, rebasing) and has nice integrations with GitHub and VS Code.
I'm sure we can, the question is, can we make an alternative to GitHub? I wouldn't be surprised if there are already several better ones, but I've never looked, because I already know Git, and my chances of convincing anyone to use a better one seem low, and they rarely seem to have as big of an ecosystem. If it doesn't have multiple clouds providers with pull requests, and at least one of those clouds providers isn'…
¿Que?
If you're wondering whether we can make something better than GitHub, there's dozens of git hosting alternatives that you might like better such as Forgejo and GitLab.
If you're saying "but I already know git", then there's still dozens of alternative hosting sites or methods!
Earlier quoted context omitted.
Before we can get a vcs that understand semantic diffs, we need a way to communicate semantic diffs. That way each file type can have its own “semantic differ”. Similar to how language servers help abstract away the differences for IDEs
Y'all know you can change the diff viewer git uses, right?
Subversion was really good. It wasn't perfect, but it was relatively painless. Instead everyone switched to a "distributed" version control system that is such a pain in the ass it is all now hosted by a single company.
Many companies host git besides github (gitlab and bitbucket to name two), and you can spin up one of your own in about 1 minute on your hardware or on a private cloud vps. A github server is much easier to set up than a subversion server. The reason people use github is because it's free, and because it has issue tracking and a wiki and forking which plain git knows nothing about.
Yes. Here are areas where git sucks: * UX, obviously. * Large files (LFS is a not-very-good poorly integrated hack) * Very large projects (big company codebases). Poor support for sparse/partial checkouts, stateful operations (e.g. git status still scans the whole repo every time on Linux), poor & buggy support for submodules. * Conflict resolution. It's about as basic as it can be. E.g. even zdiff3 doesn't give you…
Isnt one of git's core features that it can work as a patch based system?
It's my understanding (and please correct me if I'm wrong) that Linux patches can come in via mailing list, as a diff. That would make the person committing different from the owner of the change (also reflected in git's design)? Do Darcs and Pijul just have a string of patches on top of the original source file?
Subversion was really good. It wasn't perfect, but it was relatively painless. Instead everyone switched to a "distributed" version control system that is such a pain in the ass it is all now hosted by a single company.
Many companies host git besides github (gitlab and bitbucket to name two), and you can spin up one of your own in about 1 minute on your hardware or on a private cloud vps. A github server is much easier to set up than a subversion server. The reason people use github is because it's free, and because it has issue tracking and a wiki and forking which plain git knows nothing about.
And in general I feel that their gh cli tool doesn’t get enough praise. Being able to do easy API calls and queries for use in shell scripts (or just the terminal) is great, and the gh copilot is occasionally useful as a refresher for command syntax, or for deciphering some oddball git command you found online.
It’s a massive beast to tackle, and few people have a reason to. I don’t see anything doing what git does having a chance at competing with it. It requires a paradigm shift and a completely new product/approach to versioning to break the git dominance.
Git is great for keeping track of logical history, but personally I find that it is missing tools for handling physical history. Reflog is a step in the right direction but it has a limited size and AFAIK it is not possible to share a reflog between clones. Which leaves "cp -r repo repo.backup" as the best option. Of course, as long as you only do additive changes via commit/merge/revert, the logical history is equiv…
what's the difference between physical history and the logical one? thanks in advance
The complex explanation: a git repository at a particular time consists (mostly) of a graph of commits. This graph represents the logical history of code changes in the repository. The graph can be updated in an append-only fashion (using commit/merge/revert) or in a destructive way like with rebase and reset. The physical history is simply the history of the graph over time.
In my opinion the feature Git has always been missing is version control of branches. Of course the immediate consequence would be that you'd be able to roll back changes to branches but there'd be some more fundamental consequences as well. I'm pretty sure some of the problems with GUI's/wrappers around Git break down because there's no tracking of branches/tags. Besides that it's pretty much endgame in my opinion i…
Can you clarify what you mean by "version control of branches"? Branches in Git are just labels of objects. Are you talking about having a history of which objects a branch has previously labelled, like the reflog?
The way we work around that missing feature is by tagging commits so we don't forget what revision a release was made at for example. A sequence of release tags basically is a meta branch, a history of the release branch, but managed manually instead of through git.