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

131–140 of 197 posts

Re: Fossil versus Git

#131

Post by prepend »

tom_ wrote: post #79
dwpdwpdwpdwpdwp wrote: post #43

Earlier quoted context omitted.

Source control is all about managing diffs. Large files are fine, binary doesn’t make sense. Most of the time binary file diffs aren’t human readable. I store binary files outside of git but keep build logs containing binary file CRCs on git

Most binary files that people want to store in a VCS are stuff like .psd, .xlsx, .docx, and the like - data that's created by people by hand, but not stored as text.

Xlsx and docx are just zipped up xml text. You can store it as text if you like and I think there are many git modules to handle this. But the xml isn’t really that diffable so I don’t bother.

Re: Fossil versus Git

#132

Post by prepend »

IshKebab wrote: post #65
prepend wrote: post #17

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

You didn't put blobs directly in the database because of annoying database limitations , not because there's a fundamental reason not to. It's the same with Git. Don't put large files directly in Git because Git doesn't support that very well, not because it's fundamentally the wrong thing to do. There should be a name for this common type of confusion: Don't mistake universal workarounds for desirable behaviour.

The fundamental reason had to do with how rdbms structured its pages of data and having arbitrary sized blobs directly in the record broke the storage optimization and made performance tank.

It was a design constraint back in the day.

I haven’t looked at this in decades, but I think now it’s all just pointers to the file system and not actually bytes in the record.

So it was fundamentally the wrong thing to do based on how databases stored data for performant recall.

But that’s back when disks were expensive and distributed nodes were kind of hard.

Re: Fossil versus Git

#133

Post by remram »

prepend wrote: post #128
remram wrote: post #107

Earlier quoted context omitted.

> my car won’t start because I’m out of coffee grounds I'd call this a straw man but it's way past that...

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.

Re: Fossil versus Git

#134

Post by _ikke_ »

kaashif wrote: post #120
snuxoll wrote: post #93

Earlier quoted context omitted.

Because when I am developing in my local repo I have a stream of commits that go “adding xyz because abc is being a pain”. They’re informational for me as I progress through iterating on a feature, but when I’m ready to merge I really don’t want that mess polluting the global commit history. I may also be working on multiple things in parallel and want to isolate them from each other, both to keep a cleaner history b…

Rebasing to squash commits or even split commits up before/during making a PR makes sense to me and I do it all the time just to clean up my mess. The order of development and the state of the repo over time isn't faked, this is just labelling and granularity. What doesn't make sense to me is rebasing instead of merging. If master has a lot of changes and you want to pick those up, you can merge in which case history…

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 persons put all the burden on the receiving side.

Re: Fossil versus Git

#135

Post by tux1968 »

Supermancho wrote: post #124
tux1968 wrote: post #103

Earlier quoted context omitted.

> squash your commits into a single unit change. Again, Git gets its bias from Linux kernel development. You can not present your entire work as a single unit change to sub-system maintainers for inclusion in the mainline. You can use the power of Git to present it in a digestible way that aids understanding, and allows piecemeal selection of acceptable bits, and rejection of others. This is clearly not relevant to e…

> to suggest there is no value at all, is laughable. It can have no value at all to common workflows. Usually, this kind of singular change consideration is done at the PR level in another tool (github), which is divorced from git. Being able to present missteps/demonstrate specific commits where something didn't work (without another developer having to write the scenario) has utility that I have leveraged.

> Being able to present missteps/demonstrate specific commits where something didn't work (without another developer having to write the scenario) has utility that I have leveraged

Fortunately, you're able to include anything you think is relevant. If you think a change is worthy of inclusion, include it. But there are clearly things that are just silly mistakes that provide no such value, and cleaning those up as a courtesy for the person who has to review your code, just makes sense.

Re: Fossil versus Git

#136

Post by thfuran »

toenail wrote: post #52
sausagefeet wrote: post #46

Earlier quoted context omitted.

"One thing" depends on how you squint, though. If you view "version and track text information" then it makes sense to store tickets, wiki, code, yadda under the same tool.

I'm primarily a command line user, I don't use explorer to view, rename, move, copy files etc. Like I said, unix-y. If you think "manage computer stuffs" the OS should bundle all tools anybody could ever want.

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

Re: Fossil versus Git

#138

Post by masklinn »

wavemode wrote: post #117
masklinn wrote: post #100

Earlier quoted context omitted.

> Source control is all about managing diffs. Large files are fine, binary doesn’t make sense In git, diffs are literally just a UI thing.

That's not really true, is it? Surely Git does have an internal concept of diffing changes, specifically so it knows whether two commits can be merged automatically or if they conflict (because they changed the same lines in the same file).

> That's not really true, is it?

It is.

> Surely Git does have an internal concept of diffing changes

Not in the data model. Packing has deltas, but they're not textual diffs, and they would work fine with binary data... to the extent that the binary data doesn't change too much and the delta-ification algorithms are tuned for that (both of which are doubtful).

> specifically so it knows whether two commits can be merged automatically or if they conflict (because they changed the same lines in the same file).

Conflict generation & resolution is performed on the fly.

Re: Fossil versus Git

#139

Post by gcarvalho »

_ikke_ wrote: post #134
kaashif wrote: post #120

Earlier quoted context omitted.

Rebasing to squash commits or even split commits up before/during making a PR makes sense to me and I do it all the time just to clean up my mess. The order of development and the state of the repo over time isn't faked, this is just labelling and granularity. What doesn't make sense to me is rebasing instead of merging. If master has a lot of changes and you want to pick those up, you can merge in which case history…

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.)

Re: Fossil versus Git

#140

Post by Skinney »

prepend wrote: post #129
Skinney wrote: post #114

Earlier quoted context omitted.

If your car followed the unix philosophy you’d have to bring your own radio and AC.

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 drive than a car with an AC.

And, just like a car comes with a radio and AC because you likely want those conviniences, fossil comes with issue tracking and wiki because you’re likely to want that for your project. Don’t have to use it, but it’s there if you do.

Post reply on HN