Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fossil versus Git

fossil-scm.org

Post reply on HN
Print view View original

151–160 of 197 posts

Re: Fossil versus Git

#151

Post by otp209 »

prepend wrote: post #17
dognotdog wrote: post #2

I 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…

> if I have a giant binary file in source control “I’m doing it wrong” so git helps me design better

Your VCS should not be opinionated, that is not its job

Re: Fossil versus Git

#152

Post by otp209 »

mgaunard wrote: post #23
dognotdog wrote: post #2

I 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…

if you have large files in your repository, you have a design problem.

> if you have large files in your repository, you have a design problem

Your workflow and use cases aren't everyone's.

Re: Fossil versus Git

#153

Post by otp209 »

firesteelrain wrote: post #55
Culonavirus wrote: post #35

Earlier quoted context omitted.

Not in gamedev where you can have hundreds of gigs of art assets (models, textures, audio...), but you still want to version them or even have people working on them at the same time (maps...). But that is a different can of worms entirely.

Then use a binary repository like Artifactory which has LFS support. You can still version them in git- just don’t store them in there

> Then use a binary repository [...] You can still version them in git- just don’t store them in there

So git works, as long as you include things that aren't git to handle what it can't.

Stockholm syndrome really blinds people

Re: Fossil versus Git

#154

Post by thfuran »

toenail wrote: post #148
thfuran wrote: post #136

Earlier quoted context omitted.

Most popular Linux distros include a whole lot more than just a stripped down kernel.

Exactly, they include other programs. They don't ship a kernel that includes a music player.

That's a meaningless distribution as far as most OS uses are concerned.

Re: Fossil versus Git

#155

Post by otp209 »

thfuran wrote: post #121
mgaunard wrote: post #23

Earlier quoted context omitted.

if you have large files in your repository, you have a design problem.

That's a ridiculous claim. Can you really not think of a single situation in which it makes sense to keep track of big pieces of data alongside (or even instead of) source code? The fact that many VCS don't handle large binary data nicely doesn't mean there's never a good reason to do so.

> Can you really not think of a single situation

It doesn't even matter if they can think of one; assuming your own use cases for software are everyone's is proceeding from false premises and is the sort of thing that leads to (and necessitates) "hacky workarounds" and eventually the adoption of better software we should've had in the first place.

Assume nothing about user's use cases. A VCS should not be imposing arbitrary limitations on the files it's indexing. It's like the old-school filesystems we (surprise, surprise) deprecated.

Re: Fossil versus Git

#156

Post by mbivert »

hn92726819 wrote: post #87
mbivert wrote: post #85

Earlier quoted context omitted.

Versioning/distributing tickets is indeed useful; but can't this be "implemented" in git already, by defining a file-based format (think, issue/$YYYYMMDDHHMMSS-$title.md, but the variants are endless), and versioning those files? A first drawback I can think of is that this would probably require an additional layer for non-tech people. I haven't had the opportunity to use Fossil, so I am clueless regarding the kind…

Well the article does say: > These additional capabilities are available for Git as 3rd-party add-ons , but with Fossil they are integrated into the design

Ah, I probably wasn't clear enough: my point was that the core of the feature (i.e. omitting non-tech users) can be implemented so cheaply that it seems a bit superfluous to require a built-in implementation.

However, Fossil's documentation[0] has some answers:

  Some other distributed bug-tracking systems store tickets as files within the source tree and thereby leverage the syncing and merging capabilities of the versioning system to sync and merge tickets. This approach is rejected in fossil for three reasons:

  1. Check-ins in fossil are immutable. So if tickets were part of the check-in, then there would be no way to add new tickets to a check-in as new bugs are discovered.

  2. Any project of reasonable size and complexity will generate thousands and thousands of tickets, and we do not want all those ticket files cluttering the source tree. 
 
  3. We want tickets to be managed from the web interface and to have a permission system that is distinct from check-in permissions. In other words, we do not want to restrict the creation and editing of tickets to developers with check-in privileges and an installed copy of the fossil executable. Casual passers-by on the internet should be permitted to create tickets.
Point 3. indeed requires additional software;

Point 2. could be solved by storing the tickets in a distinct repository.

Regarding point 1., as far as I understand, a check-in is an atomic series of modifications to the repository database, so it seems there is a strong correlation between the tickets and the "commits"? If so, why not, but I'm not sure why this is necessary either.

[0]: https://www.fossil-scm.org/home/doc/trunk/www/bugtheory.wiki

Re: Fossil versus Git

#157

Post by rewmie »

bradley13 wrote: post #88
bloopernova wrote: post #64

Earlier quoted context omitted.

Regarding rebase, it's been my experience that among many developers rebase has a mythical status. You're "supposed to" rebase, but no one knows the benefit of doing so. It's a big downside of git being treated like some magical difficult spell. Same with exiting Vim, people treat it as way harder than it really is.

I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? The project is what it is. What happened, happened. If there are a couple of weird commits, who cares? At most, maybe edit the commit messages to explain.

> I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history?

There are plenty of reasons if you're doing non-trivial tasks on local branches within a team. I've mentioned a common usecases I have, which is to reorder commits I make in local branches to afterwards peel them off as stand-alone pull requests.

Re: Fossil versus Git

#158

Post by otp209 »

probably_wrong wrote: post #95
wirrbel wrote: post #18

I once tried it and ended up losing the history for some weird reason. Maybe its a fixed bug by now, but if I don't want to use git, I will use mercurial.

I lost all of my changes the first time I used git, which was the same time I found the error "cannot merge because you have unmerged files" (cut to me yelling "I know, that's why I want to merge!"). I have not yet forgiven git for that, but I'll reluctantly accept that me not knowing how to use the tool is not entirely the tool's fault. Also: I stand 100% by your alternative solution because Mercurial rocks.

>but I'll reluctantly accept that me not knowing how to use the tool is not entirely the tool's fault

I don't buy this. A good tool should do its job and stay out of your way. The amount of pointless knowledge I now have just to be able to use a version control system for my job still to this day annoys me.

Linus Torvalds isn't some infallible god, and it may be useful for linux kernel development, but we're not all linux kernel developers; and tools like VCSes, when designed well, should be unnoticed until the exact moment you need them, convenient and simple to use, and not get in your way or create problems for you where there weren't any to begin with. (Holy run-on sentences, Batman!)

In contrast, git goes out of its way to throw itself in your face at every opportunity, exacerbate your problems, and create a maze you either have to navigate precisely or just decide "fuck it" and do a copy/replace file trick just to get back on track with what you were actually doing.

The fact that people keep prescribing "just learn all its intricacies" or other band-aids (like the other "use with" software suggestions here) rather than even acknowledging it as a problem, to me, points to the lack of UX expertise in the field, and to stockholm syndrome.

(Which, funnily enough, is a problem things like git contributes to. It being one of the first things required to learn in CS, I constantly wonder how many of my peers might've switched out of the field given the mess it is, assuming CS wasn't for them. And, in turn, the breakthroughs we might've missed out on having earlier.)

Tools should be simple and usable, not throw up arbitrary barriers to entry.

Re: Fossil versus Git

#159

Post by prepend »

remram wrote: post #133
prepend wrote: post #128

Earlier quoted context omitted.

It’s an allegory, not a strawman.

Fossil's source control doesn't break if the issue tracker or wiki is misconfigured or disabled. Just like your imaginary car-with-a-coffee-machine would not fail to drive if it were out of coffee grounds. Saying "I don't want my version control to break because of misconfigured wiki" would have already been a straw man, adding this BS about cars making coffee just makes it more insane of an argument.

I disagree. Im sure fossil designers don’t want the whole thing to break if the wiki breaks, but have you tested it? I don’t know what dependencies it has or how well it’s designed. Im not worried about it being turned off. I’m worried about a bug in the wiki portion killing the “important” version.

But my argument is that I don’t want my important thing I care about doing unimportant things I don’t care about.

I love wikis and I love coffee. But I don’t want to have to install a wiki just to use source control.

I love used enough systems where stuff breaks because of a particular feature I didn’t know about and certainly don’t want (atlassian) to be wary of things.

And while the car / coffee maker allegory is funny, I wouldn’t be surprised if a car does break in the near future because some dumb feature can’t phone home and validate. Or the battery died from some process that kept running and was completely unnecessary.

Re: Fossil versus Git

#160

Post by otp209 »

henrydark wrote: post #36

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…

> 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?

THANK YOU. Fucking prescriptivists ruin everything.

Post reply on HN