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

Fossil vs Git

fossil-scm.org

Post reply on HN
Print view View original

141–150 of 252 posts

Re: Fossil vs Git

#141

Post by __MatrixMan__ »

marktangotango wrote: post #44
gugagore wrote: post #34

Earlier quoted context omitted.

I'm also a big fan of not deleting data. I don't like squashing commits, for example. But I also want to be able to see high-level intent. If instead of "squashing", it were "grouping", I'd be happy. I could encapsulate a bunch of messy commits that I made while I didn't know what I was trying to do. The intent would be clear at a higher level, but if you want to dig in to see what it actually took me to achieve that…

How often dou you actually look at this historic detail you seek to maintain? Daily, weekly, monthly? Is it more for to satisfy a feeling than an actual need? I mean if some junior dev wallows on some branch for 40 commits, I don’t want to see any of that, I just want to see what was finally merged.

I like to write tests (in a separate repo) which iterate over each commit and mark the point in history where they start passing--which is usually when the feature was implemented--and (more importantly) the point in history when they start failing again.

These points usually indicate communication/comprehension errors involving two developers. When I bring the problem to the developers' attention, their reactions differ based on their commit style. If they have atomic commits it's usually a five minute conversation because the nature of the problem is immediately apparent. If they have large squashed commits, I usually have to bring both developers together and have them fight over whose problem it is.

So I would say... a couple times a week, but the overall time savings of finer granularity is significant because it limits the number of parties that end up huddled around a single screen.

Re: Fossil vs Git

#142

Post by teeray »

randallsquared wrote: post #124
jlebar wrote: post #94

Git: One check-out per repository Fossil: Many check-outs per repository git allows multiple checkouts per repo. Official docs (good luck): https://git-scm.com/docs/git-worktree Random person's blog that explains it more clearly: https://www.saltycrane.com/blog/2017/05/git-worktree-notes/

I have no idea what use case is satisfied by git worktree, based on that blog post. In the case that you desperately needed to have two branches checked out, why not just clone twice?

I use it to build multiple versions of Go from source locally. When a new release branch appears, I just `git worktree add release-branch-1.12 ../go1.12`, then `cd ../go1.12/src` and `GOROOT_BOOTSTRAP=../go1.11 ./make.bash`. It makes it very easy to try out betas while staying in sync with patch releases. It’s also great for keeping an old version of Go around if you have some project that requires it.

Re: Fossil vs Git

#143

Post by fiddlerwoaroof »

paulddraper wrote: post #113
emerongi wrote: post #74

Earlier quoted context omitted.

Huh. I've just used another git clone of the repo, but the worktree command seems to fit my uses very well. Thanks.

Git clone is still a fine solution, and the one I prefer. Worktree adds the ability to share config and save disk space.

The other advantages of worktree are: you can update the remotes of all the checkouts at once with git fetch and you can see all the places your repository is checked out with a git command.

Re: Fossil vs Git

#144

Post by bch »

cuspycode wrote: post #137
bch wrote: post #99

Earlier quoted context omitted.

I use it for lots of projects, spanning years of work, including commercial projects with ~20 devs. Those projects aren’t public, and I’m sure lots of other people do use it that way. It’s still not going to rival the install base of git.

I use it too. I like to self-host my commercial projects, and when I decided to move away from Subversion about seven years ago I did consider Git, but the ease of self-hosting Fossil made the choice for me. Just plug it into apache httpd and off you go. Some time later GitLab became available, so now I'm also running a GitLab instance. But the Fossil server has much smaller footprint and is easier to manage.

The ease of use/management is a big deal, and to an extent I think it falls out of technical design decisions (proper database for repo storage that fully, easily, obviously allows first class multiple checkouts of a single repo instance). Others are philosophical design decisions, most of which I think I like, some I think I don’t, and others that just aren’t in place yet. Key is it’s nice to work with, and if I’m doing development/management, as much as possible I want it to be an enjoyable experience.

Re: Fossil vs Git

#145

Post by orev »

As someone not versed in either, how much does not being able to track changes forward through the history matter? It sounds like that might be pretty important, but git’s popularity would seem to indicate that it doesn’t really matter in practice?

Re: Fossil vs Git

#146

Post by peteforde »

jordigh wrote: post #87
gugagore wrote: post #34

Earlier quoted context omitted.

I'm also a big fan of not deleting data. I don't like squashing commits, for example. But I also want to be able to see high-level intent. If instead of "squashing", it were "grouping", I'd be happy. I could encapsulate a bunch of messy commits that I made while I didn't know what I was trying to do. The intent would be clear at a higher level, but if you want to dig in to see what it actually took me to achieve that…

You misunderstand me. Almost everyone does. I do not think you should squash all of your changes into a giant hairball commit, and I don't think first parent (which is effectively the same thing) solves this problem either. I think each of your commits should be individually rewritten until each commit makes sense and tells a single, indivudal story that makes sense on its own, while at the same time be completely at…

While I am following this conversation closely, I wanted to politely make a suggestion about something you said:

"You misunderstand me. Almost everyone does."

That sounds really frustrating. It's not clear from your post whether you mean this as "everyone who reads this comment does not understand me" or "people frequently misunderstand me"... but typically, someone who feels this way experiences this in the latter, general sense.

Good news: it is possible to dramatically improve the ratio of people who understand you. It will, however, require that you change how you communicate some kinds of information.

What I'm saying is that if people don't understand you, the first place you need to look is your own tools for communicating with people. Of course, what you are saying makes sense to you. But there's an intellectual fallacy at work if you assume that "almost everyone" is the problem and you are the solution. :)

Have you ever heard the saying, "The only thing all of your crazy ex-partners have in common is you?"

There are people who are tasked with explaining far more complicated concepts than source control who people claim to love learning from. That means there is hope for us all.

Re: Fossil vs Git

#147

Post by kzrdude »

randallsquared wrote: post #124
jlebar wrote: post #94

Git: One check-out per repository Fossil: Many check-outs per repository git allows multiple checkouts per repo. Official docs (good luck): https://git-scm.com/docs/git-worktree Random person's blog that explains it more clearly: https://www.saltycrane.com/blog/2017/05/git-worktree-notes/

I have no idea what use case is satisfied by git worktree, based on that blog post. In the case that you desperately needed to have two branches checked out, why not just clone twice?

Shared set of local branches, they might be many

Re: Fossil vs Git

#148

Post by Pxtl »

marktangotango wrote: post #44
gugagore wrote: post #34

Earlier quoted context omitted.

I'm also a big fan of not deleting data. I don't like squashing commits, for example. But I also want to be able to see high-level intent. If instead of "squashing", it were "grouping", I'd be happy. I could encapsulate a bunch of messy commits that I made while I didn't know what I was trying to do. The intent would be clear at a higher level, but if you want to dig in to see what it actually took me to achieve that…

How often dou you actually look at this historic detail you seek to maintain? Daily, weekly, monthly? Is it more for to satisfy a feeling than an actual need? I mean if some junior dev wallows on some branch for 40 commits, I don’t want to see any of that, I just want to see what was finally merged.

I'd rather have it and not need it than need it and not have it.

Besides, squashing means the identity of the commits changes, doesn't it? So you can't merge the same branch into 2 different branches (like merging a bugfix into both the release branch and the trunk) while keeping the identity of the commits - then when you merge your release branch into your device branch you get wonky duplication of commits in the history.

I notice that move detection seems to get messed up by squashing sometimes...

But maybe I'm using Git wrong, which imho is the biggest flaw of Git - it's so flexible that there are so many ways to "use it wrong".

Re: Fossil vs Git

#150

Post by rwbt »

stesch wrote: post #131

Would you recommend using fossil for Unity3D projects? Needs to exclude certain files and being able to deal with binary files.

Just giving my experience - I working in rendering graphics and use fossil for version control. Some of my repos are more than 100GiB in size and fossil has no problem with it. Fossil handles binary files adequately but the only catch is file size is limited to SQLite 'Blob' size limits (which is currently 2GiB). So if you have asset files larger than 2GiB, you'll have to split it into multiple files.
Post reply on HN