Lots of people are saying that having large files in a repo is wrong, bad, bad design, incorrect usage. Forget that you know git, github, git-lfs, even software engineering for a moment. All you know is that you're developing a general project on a computer, you are using files, and you want version history on everything. What's wrong with that? The major issue with big files is resources: storage, and network bandwi…
Git is designed with a strong emphasis on text source and patches. It simply isn't designed for projects with large assets like 3D animation, game dev, etc. Having said that, solutions like LFS, Annex and DVC (not git-specific) work really well (IMO). If you don't like that, there are solutions like Restic that can version large files reasonably well (though it's a backup program).
Fossil versus Git
161–170 of 197 posts
Re: Fossil versus Git
#162Earlier quoted context omitted.
Right. It’s a careful balance of what to include and what not to include. I don’t know the exact dividing line for “do one thing” but I think that modularity and composability is important. I like having an AC in my car. But I don’t want AC to be a dependency for my car. I like chaining tools together, but work to minimize the required dependency among tools. I think in principle, it’s good if you can install compone…
Fossil doesn’t have a dependency on chat, forum, wiki or issues. They’re included, part of the same product. But if you don’t want it, then you don’t have to use it. Just like you don’t have to turn on the radio or AC in your car. Just like all the email related stuff in Git. And, just because they’re included doesn’t mean they detract the value of the other stuff that is there. A car without an AC isn’t better to dr…
I think this is a philosophical preference.
I think they do detract because they make the system more complex. And fossil developers work on that instead of the think I want. So there’s a cost there.
Having an AC and radio in a car increases its price. Not by much but by something. If designers didn’t work in the AC, there would be something else they put in. Or the car would be simpler.
I definitely want an AC in every car I buy. Maybe a radio. So I don’t mind they they’re bundled.
I’m sure the people who want wikis and chat in every repo like it too. Good for them, use it. I wish them the best. I don’t like it and think it detracts from their product.
I consider them more like project management or collab software with a custom vcm built in. And so I’d rather prefer some collab stack that uses the best vcm stack I think is out there, git.
So they’re on a tough spot because they’d be better off just selling all their GitHub-competitor features without trying to convince people to switch off of git.
Just like a car coffee maker company would be better off just making coffee makers they fit into popular cars rather than trying to make a literal car.
Re: Fossil versus Git
#163Re: Fossil versus Git
#164Unfortunately for git alternatives, the momentum behind git is in large part pushed by the "social network" aspect of GitHub. In the past I used Mercurial, among other things, for my open source work. And various issue trackers of my own choosing. I am not particularly wedded to Git. But I keep getting sucked into GitHub these days. To get publicity or outside contributions it's hard to avoid the GitHub trap. It's be…
And there was a time everyone thought facebook wouldn't dethrone myspace, [something.js] wouldn't replace [somethingelse.js], and so on.
First mover doesn't mean a lot in software. The network effect you brought up does, but there'll be plenty of people who don't want to get caught up in that "trap" and git/MS-land to seed a decent alternative. (Why should your code discovery networking site be prescribing your choice in VCS, anyway?)
Re: Fossil versus Git
#165Earlier quoted context omitted.
To clarify the actual benefit: this means that tickets, etc. are also distributed, i.e. available and backed up locally with every contributor, and not dependent on lock-in to a single vendor like GitHub. Edit: and yes, of course there are downsides as well. It's up to you to weigh them against each other.
I understand, I don’t care about that.
As the git people love parroting of its myriad kitchen sink commands, "if you don't like it you don't have to use it".
I'd rather have a single integrated tool than the shopping list of "just use X and Y and Z" people are prescribing in this thread for getting the so-called git ""ecosystem"" ""working"".
Not that I'll necessarily use all the added features; but the ones I do want being integrated is absolutely relevant to my interests.
Re: Fossil versus Git
#166Been using fossil for several years on my solo projects and loving it. Hoping to see it get wider adoption.
Re: Fossil versus Git
#167I keep coming back to fossil again and again, despite git having a huge pull because of the easy publishing and collab on github/gitlab. Just the other day I was starting an exploratory project, and thought: I'll just use git so I can throw this on github later. Well, silly me, it happened to contain some large binary files, and github rejected it, wanting me to use git-lfs for the big files. After half an hour of no…
It is extremely rare that I have a file over 100MB. I also think it’s one of those situations where if I have a giant binary file in source control “I’m doing it wrong” so git helps me design better. It’s like in the olden days when you couldn’t put blobs directly in a row so databases made you do your file management yourself instead of just plopping in files. I like git. I don’t like giant binary files in my commit…
Re: Fossil versus Git
#168Unfortunately for git alternatives, the momentum behind git is in large part pushed by the "social network" aspect of GitHub. In the past I used Mercurial, among other things, for my open source work. And various issue trackers of my own choosing. I am not particularly wedded to Git. But I keep getting sucked into GitHub these days. To get publicity or outside contributions it's hard to avoid the GitHub trap. It's be…
> Unfortunately for git alternatives, the momentum behind git is in large part pushed by the "social network" aspect of GitHub And there was a time everyone thought facebook wouldn't dethrone myspace, [something.js] wouldn't replace [somethingelse.js], and so on. First mover doesn't mean a lot in software. The network effect you brought up does, but there'll be plenty of people who don't want to get caught up in that…
I had hopes for bitbucket for a while, but it stagnated, and then Atlassian got their mitts on it.
Re: Fossil versus Git
#169Earlier quoted context omitted.
It is extremely rare that I have a file over 100MB. I also think it’s one of those situations where if I have a giant binary file in source control “I’m doing it wrong” so git helps me design better. It’s like in the olden days when you couldn’t put blobs directly in a row so databases made you do your file management yourself instead of just plopping in files. I like git. I don’t like giant binary files in my commit…
I fail to understand people that can't be bothered to empathize with other use cases than their own. Game development usually has a large number of binary assets that need to be in source control, does that sound like a reasonable use, or are they also doing it wrong?
Re: Fossil versus Git
#170Earlier quoted context omitted.
Lots of criss-cross merges make it really difficult to follow history, making it less useful. Note that merge vs rebase a false dichotomy. After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit. In the end, it's about commutating your changes effectively. The less noise there is, the better you can communicate. That takes effort from both sides, but many person…
> After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit You can push directly to the target branch. git push origin my-branch:master If your branch is a direct continuation of master -- which is often the desired result of rebasing -- then no merge and no force-push are necessary. (I'm not saying this is a good workflow, btw.)