201–210 of 309 posts
But yes, I think we can.
Almost everything can be better:
* Merges/rebase/branch management.
* Project management.
* Diff.
* Large files.
* User management.
* Partial checkouts.
* ACID semantics.
* Binary file management.
* User experience, including making it accessible to non-technical folks.
* A bunch of others.
Along what axis do you want the VCS to be "better" than git? For example, git's cli user interface is monstrous (yes, I know, you personally have 800 cli commands memorized and get them all right every time, that doesn't make it "good"). From the outset, the maintainers of git basically decided "it's too much work to make all the cli flags behave and interact consistently" so they didn't. This allowed git to grow fas…
I generally don't hear too many complaints about GIT in the Windows/.NET development world, probably because there are good UI front ends and there's not as much 'tough guy' cred from sticking to the CLI. Visual Studio does a decent job of abstracting the GIT nuances, but I personally use GIT Extensions, which looks and feels much better on Windows than the other cross platform UIs. I drop to the CLI occasionally, es…
That’s probably really all there is to these discussions, good old technocratic chauvinism :)
Earlier quoted context omitted.
GitHub is the one everyone else uses though, which means you can have everything in one place, so they have the advantage. There are others that are almost as good, I suppose what I should have said is "Can we make something better than GitHub for the hypothetical better non-git VCS", since without that it's hard to imagine using anything but Git.
Pretty sure alternative git services are still larger than alternative source control systems, yet OP is asking about alternatives to git which will be even smaller. The whole point is that the person wants to use something else. If your argument is that Microsoft GitHub is the largest and therefore the best, it's circular reasoning and will forever remain that way. We should all stay on Facebook also if they're the…
I could imagine people switching if someone made another site with some kind of killer app and promoted it with a million dollars of ads, but... At the moment, the only feature the alternatives focus on is usually privacy, which is clearly not enough to make average people switch.
Network effects aren't the only factor that matters, just a really big one for most.
Earlier quoted context omitted.
While I feel like this is generally true for most programmers and knowledge workers, Git is absolutely not suited to the workflow of several industries, including the one I work in: games. Working with an engine like Unreal Engine for a project of any reasonable size requires working with both hundreds of thousands of active files (my current project's repo's HEAD has ~400k) and hundreds of gigabytes of active files,…
This is a solved problem with git. I’ve worked on bigger projects than yours with histories that are so big you can’t clone them if you wanted to. I’ll make a note to drop what to google for tomorrow, but basically the history is fully available but git knows how to query it over the network. When you open a file, it loads it over the network. Remote build systems do your builds. Most of this was built by Microsoft t…
Earlier quoted context omitted.
> A github server is much easier to set up than a subversion server. You can't set up a GitHub server.
The intention I got from @dreamcompiler was that "A git server is much easier to set up than a subversion server.", which I feel is true.
Although...you can set up a Github on-prem server -- or at least this used to be true. Talk to Github Sales and be prepared to write a check.
Earlier quoted context omitted.
The git model has fundamental limitations because it saves snapshots rather than changes, and doesn't capture some metadata changes like renames. A tool like Darcs or one of its spiritual descendants will have fewer merge conflicts than git. Totally agree on your main point though. The benefits of switching are far lower than the costs.
> doesn't capture some metadata changes like renames If you rename the file using git and that is the only change in your file, then it works: git mv oldfile newfile Commit that change and the rename is in your history.
Yes. IMHO the next VCS model should follow a centralized-first, decentralized optional model. Which would be a flip of the decentralized-first model of git. I also think GitHub is in a unique space to really innovate on git and it’s a shame they’re not. For example, I shouldn’t need to make a fork to make a PR. That’s absurd and the GitHub server should be able to apply ACLs based on the push identity. There’s a coup…
I think there are some serious ergonomic issues with forks as they’re presently implemented. However, I’m curious what you intend from: > the GitHub server should be able to apply ACLs based on the push identity That’s essentially exactly what a GitHub fork _is_ – an ACL’d set of refs you’re allowed to control, separate from upstream’s set of refs. I guess – what would you have us do differently? Disclosure, I work f…
Earlier quoted context omitted.
the rename won't be in your history because the tree and commit objects don't support renames the tooling infers a rename based on the lack of a content change
Is there a difference?
A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen. I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare…
All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Git solves the deeply complex problem of distributed version control. Most complaints about git…