171–180 of 454 posts
I am not a Git fan. The most perplexing to me is how huge companies spend 100.000s (1.000.000s??) of $$ to hack Git so that it will git with their needs. Like Google. One of the biggest issues seem to be the size of the repo, which takes days (?) to download and get started. Does Google contribute all their extra services / tools to make Git for work for then?
i guess you use what you have, and don't use what you don't have, but i don't really know when i've ever thought let me see what happened after that branch was merged into future. I do have a simple script that will list what branches were merged into the current branch in git. That is useful, so being built in, in Fossil is useful i guess. My gripe with Fossil, is not technical, it is really just who uses it? How mu…
It's also the perfect example and test of sqlite itself, an scm that is a one stop shop for the entirety of the project, remaining as responsive no matter the increase of the scm db itself.
Most of these arguments are nonsense. "Standing up a git server is non-trivial." It's literally just "git init" and providing ssh access to the directory. Most of the other ones seem to suggest the author never learned git. git has a beautiful data model and a horrible user-space to poke at it. Writing a new user-space makes sense. This seems to poorly re-invent the data model, by virtue of not bothering to understan…
> and providing ssh access to the directory Well, doing that securely and somewhat aclainf isn't easy and file access permissions are a pain. If you remember to update the index regularly serving .git via HTTP is easy for read-only access, but all else is quite a bit more involved.
I read this years ago, and it really showed me the light. I've used fossil and run it on my own server and it is a dream to work with. I hate working with git, but I do it reluctantly. I'd rather use fossil any day.
Seems like a textbook example of NIH to me. By the time you understand git well enough to design a good replacement, you’re bound to be an expert and ought to appreciate more the design of git. If you don’t like the lack of a good GUI or web application, you can just build one that works the way you want and still works with git.
Not to be whiny, but we had better versions of git before git was the standard. I'm thinking specifically of Mercurial.
The CTO was very vocal about how Mercurial was better, but all the use cases he toted weren't really that meaningful. Eventually when BitBucket removed Mercurial support we switched to git. I'd used git previously and hadn't really understood the advantages of hg, and after we switched to git there was no difference in productivity.
Mercurial wasn't better, it's just slightly different enough to have a holy war over.
https://git-man-page-generator.lokaltog.net is the funniest thing I've seen in a while
Earlier quoted context omitted.
FWIW, that isn't actually part of the core git binary. Because unlike fossil, git is a collection of executables, not just one.
Yes, which is why git is a pain in the butt to install and you have to rely on your OS packages (which includes all the kitchen sink stuff) or a GUI installer with all the necessary dependencies vs. Fossil which is just download executable and done.
I mean like, I have space for millions of kitchen sinks now. Considering that, I kind of refuse to accept that out of all things, bundle size is a valid distinction criterion for VCS‘es.
Earlier quoted context omitted.
git...is difficult to install? What's difficult about apt-get install git?
These is exactly what my first thought was! Installing open-ssh and git is kind of my first activity on a new computer. But I believe they are talking about setting up a git server. The thing that we rely on GitHub/GitLab/Bitbucket for. Richard counts them as an added dependency. (I mean, he is not wrong in being worried about that. You are basically giving your all your code to a company. Which does not matter for o…
Earlier quoted context omitted.
I have no idea why Richard focuses on such things but: I'm old enough to remember when developers spent time making sure they could plow all of their build assets into a single binary distributable. It often had kind of a zest to it and when you dealt with software had directories full of stuff it looked both "corporate" and "sloppy". I've never quite gotten over the feeling that the piles of dynamically linked libra…
A dynamically linked library need only have one image of itself in memory. If you are running a process that, for example, forks 128 of itself, do you want every library it uses to have a separate copy of that library in memory? That's probably the biggest benefit. But it also speeds up load time if your executable doesn't have to load a huge memory image when it starts up, but can link to an already in-memory image…
I'm not sure about Windows and Mac, but Linux uses "demand paging" and only loads the used pages of the executable as needed. It doesn't load the entire executable on startup
Earlier quoted context omitted.
Yes, which is why git is a pain in the butt to install and you have to rely on your OS packages (which includes all the kitchen sink stuff) or a GUI installer with all the necessary dependencies vs. Fossil which is just download executable and done.
git...is difficult to install? What's difficult about apt-get install git?