When they say Git, isn't Github and Gitlab they actually mean?
Is Git Irreplaceable? (2019)
61–70 of 559 posts
Re: Is Git Irreplaceable? (2019)
#62Earlier quoted context omitted.
Exporting to Git: You set a "Git mirror" once, optionally with a remote URI, and call fossil's export routine. Example: I wrote a cronjob that runs once every night that does nothing but update my Git mirrors from the current Fossils. cd $FOSSILDIR for f in *; do /usr/local/bin/fossil git export -q -R $f done Importing works... similarly. :-)
Hmm, but does importing keep all your issues, etc? I imagine it just imports the new commits?
Fossil cannot import things from Git which Git does not store. Git has no issue tracker.
Re: Is Git Irreplaceable? (2019)
#63Earlier quoted context omitted.
> unfortunately still Subversion Which is a better choice than Git for most projects, to be honest.
Everyone's has their own tastes and preferences, of course, and I respect that yours is different than mine. That said, I used and loved CVS and then SVN for years and didn't get why all the kids were fussing around with this new Git thing. I finally made myself try it for about a week. At the end of that experiment, I ported all my repos from SVN to Git and quickly set to purging all Subversion-related knowledge fro…
I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). I switched to git mainly because my colleagues were all using it. I found it difficult to use, at first, because of my expectation of a central repo. Many years in, however, I see extreme value in having all your history locally. Specifically, never having to worry about a server crashing or your "host" going out of business.
Re: Is Git Irreplaceable? (2019)
#64Re: Is Git Irreplaceable? (2019)
#65Earlier quoted context omitted.
SVN also had serious difficulties and performance limitations which git does not. Git is somewhat confusing to use, but not enough so that anyone really cares all that much (besides a few people who really care) and that is not a recipe for easy replacement. There were/are slightly less confusing version control systems (mercurial) but they didn't catch on for whatever reason.
Doesn't git fall apart for long wide checkouts and large files?
Git doesn't work very well when trying to version control things which aren't text and are large binary files. There's an acceptable workaround which is only a little awkward with git-lfs.
The general consensus is that putting big files in git means you're doing something wrong and the problem is with your environment not git. (or there are special-purpose tools for your kind of workflow which handle the specifics of your use case, like CAD/CAM/etc.)
Workflows like that generally don't fit into nice little boxes anyway the way source code management does.
Re: Is Git Irreplaceable? (2019)
#66The cloud is going to change a lot of stuff, file-system based code might be gone, code-in-database is already halfway here ... opportunity
I'll believe it when I see it and it's an actual improvement. It's not like "cloud" is some sort of Platonic embodiment of goodness and anything that is "cloudier" than an alternative is automatically better. All the attempts to put code in "databases" I've ever seen make easy things sorta easy and make medium things way harder and you can just forget about hard things; if I can't do the equivalent of "perl -pi -e 's/OldVariable/NewVariable/g' then it just isn't going to displace a file system for me. Not because I need that exact commmand or perl, but for what it represents, the ability to just do things to my code as needed, without needing to wait for someone to implement an API or sluggishly do it over a network. Another example would be just throwing a code analysis tool at my code without needing some sort of permission from my "cloud code provider".
File systems haven't been disappearing, they've just been getting hidden from users. I have seen exceedingly little evidence that anything beyond merely hiding them is actually happening in the industry. "Stick all the files in databases" seems to be seeing no penetration beyond music collections, which at this point, I think we can call a "mere use case" rather than the vanguard of a revolution, since it's a good 10-15 years old minimum.
Re: Is Git Irreplaceable? (2019)
#67Re: Is Git Irreplaceable? (2019)
#68I'm working on a git replacement, in a way. The thing that makes git powerful is that its just text. Git is probably the most powerful thing for code as text. When code no longer is just text (and by "text" I mean bytes on disk, not that we're switching to coding with emoji or VR) you get to do more powerful stuff. Our plan in Dark ( https://darklang.com ) is to combine all the different ways that people "branch" (de…
Sounds intriguing! Can you say more about what that single concept is and how it works?
To be clear, it's two concepts, one for branches and one for comments.
The first concept we've been calling deployless, and discussed it here: https://medium.com/darklang/how-dark-deploys-code-in-50ms-77...
The second one is just an idea right now, suggestions welcome. The observation is that comments on a particular line of code are spread in as many as a dozen places (a google doc, slack, trello, the code itself, an old version of the same code, PRs on github, comments on commits on github, commit messages, another place in the codebase referencing this one, the docs folder in your repo, another repo that uses this API, your 3rdparty docs on README.io, etc). This is weird and bad, and it must be possible to do better.
Re: Is Git Irreplaceable? (2019)
#69Re: Is Git Irreplaceable? (2019)
#70When people talk about killer features missing in Git, there is more beyond the UX and mono/poly repo. One thing is code review. There is no code review in Git. What I expect in 2020 is that I should be able to specify reviewers for the commit (which I pick out of a list of people who can approve it). These people should be able to leave comments on the commit. I should be able to both respond to comments and modify…
I think it doesn't exist because there is no demand for that to be part of the codes history. Nothing you've described sounds very useful after a month or so.