4 ms·
There are significant pockets of non-git users in the developer community ;) I find hg much more pleasant to use than git, and can generally still work in git
by srer 4y ago
There are significant pockets of non-git users in the developer community ;)
I find hg much more pleasant to use than git, and can generally still work in git based teams while using hg.
I find pijul's approach much more interesting than git's, and look forward to pijul (and others :) pushing forward how we do revision control.
I don't believe git to be the end of the evolution of revision control systems (which for me has looked like cp -> rcs -> cvs -> svn -> git|hg), and find git lacking enough that I look forward to what the next generation does.
Would I argue that you personally should branch outside of your git centric world? Of course not! Just as I've worked with many devs who live their lives gainfully employed only knowing Java, or sys admins who only know Microsoft, it is up to you as to if you wish to explore different approaches and styles to achieve your end goal.
- cortesoft 4y agoSure, their are developer communities around the other SCMs, and many are passionate about those alternatives. My point is that even if you do get into one of those other communities, you are still going to have to learn how to use git because so much of the world uses it. You will need it either for your job or because the open source project you want to use is on it. You can't skip learning git. If you don't mind that, then go for it. For me, I don't want to use my limited capacity for learning things on learning a second (or third, since I still have SVN usage somewhere in my brain) SCM.
- olig15 4y agoThat’s not true. I’m a gamedev and have never had to learn git. The closest would be downloading a zip from GitHub. Almost all game dev is done on Perforce due to the enormous asset sizes we work with.
- johnny22 4y agoso you're saying contribute to absolutely no 3rd party code? The person is saying that if you spend time outside of your VCS bubble, then you will end up using git, even if you don't like it.
- olig15 4y agoCorrect. The dev teams working on the ‘client’ part of the game (ie, the game) don’t have time to be contributing code to open source projects, but we don’t use much open source code anyway. But other teams within the company will be using Git for server code, and other non-client side work. I’m not saying that Git is never used in game dev (it absolutely is), I’m saying that not everyone will have to learn it, or ever touch it.
- nine_k 4y agoWith insane schedules of game dev, I'd be surprised if they could contribute something back, except by open-sourcing their older code.
- davemtl 4y agoAlso in gamedev. Git doesn't work for larger AAA projects, as it often chokes on the amount of data that stored by production teams, even when LFS is used. Perforce can handle huge binary files relatively easily in comparison.
- srer 4y agoReminds me of discussions I had in the early 00's! People would say "Linux is cool and I'd like to try it, but Windows is where all the jobs are". It's a fine point, and quite reasonable. It is however I think important that we don't all take your approach.
- bborud 4y agoThe thing about Linux in the early 00s was that to a significant portion of developers, it was already obvious where things were headed. Anyone not seeing the potential wasn't really paying attention. And one shouldn't care what people who aren't paying attention think. How likely is it that Fossil will displace Git? If you believe it is likely, then learning it, and using it for projects, may be time well spent. But even then, it'll take so long that you will still have plenty of time to adapt. So perhaps it is something you should keep an eye on, but not worth investing in now. If you find Git to be a pain, then a better investment right now, which pays off right now, would be to figure out what you can do to get along with Git, and thus most developers. You have to treat learning as an investment. Which means, you have to think about about returns on investment. And just like regular investments, it doesn't matter what people who don't pay attention think.
- cortesoft 4y agoDo you really think other SCMs are going to take over git like Linux has in the server industry? Also, I wouldn’t put the choice of SCM at the same level as the choice for OS.
- inferiorhuman 4y agoEventually? Sure, nothing is forever. But the replacement won't be by something older like p4 or hg. The real question is: has the replacement been written yet?
- ghoward 4y agoNot yet. I'm getting there though. :P
- Bjartr 4y agoThe existence of tools like hg-git mean you can work with git repos without knowing the git tool itself.
- yjftsjthsd-h 4y agoThe bar is a lot lower; sure, you might want to be able to use git, but if you're only using it enough to interoperate you don't need to know how to do fancy stuff and can get by with a subset of common commands (if you only clone, pull, commit, and push, then you can just about s/hg/git/g) and ugly fixes (why learn to rebase when you can make a fresh clone and hand-pick changes?) without feeling bad about it.
- Aeolun 4y agoI’m just waiting for the next VCS that brings significant changes. We’d absolutely switch over if there was some feature we wouldn’t get elsewhere. But it’d need a couple of months/years of sustained advocacy.
- yjftsjthsd-h 4y agoIf they ever fix the performance issues and get a little polish, the patch-based DVCSs (pijul et al.) will be a great improvement in usability. If I were guessing, I bet on that as the next step (given the understanding that predicting the future like that is a fool's game).
- normie3000 4y agoPatch-based like svn?
- yjftsjthsd-h 4y agoSorry, I didn't use SVN enough to answer that. Basically, they're distributed VCSs like git, but where git stores commits, that is, snapshots of what the files look like at a specific commit, patched-based VCSs in the darcs "lineage" store diffs. Obviously the end result looks similar - git gives you diffs by comparing commits, darcs replays diffs to instantiate what the files actually look like at any given time - but it (allegedly) makes it much easier to handle arbitrary merges and do things like maintain a branch that's just like another branch but with a single commit on top.
- imiric 4y agoThe next big thing will be semantic code versioning. I.e. a tool that understands language syntax and can track when a symbol is changed. There are already experiments in this area[1], but I don't think any are ready for mass adoption yet. The fact that it's 2022 and we're still working with red/green line-based diffs is absurd. Our tools should be smarter and we shouldn't have to handhold them as much as we do with Git. It wouldn't surprise me if the next big VCS used ML to track code changes and resolve conflicts. I personally can't wait. [1]: https://github.com/GumTreeDiff/gumtree https://github.com/GumTreeDiff/gumtree
- devoutsalsa 4y agoFossilHub sounds a like social coding for old farts.