Fossil vs Git
131–140 of 252 posts
Re: Fossil vs Git
#132Git: 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?
A 'git checkout' on a large repository such as the Linux kernel may take a while (bound by I/O performance). Regulary switching between branches with many changed files becomes annoyingly slow.
If you keep multiple clones, you actually keep multiple copies of the full history, which seems like a waste of disk space (yes, deduplicating filesystems exist, but are rarely used).
git worktrees are also very useful if you have unfinished on a release branch. You do not have to make temporary commits or stashes you forget about, you can just leave the modified files as they are and switch to a different worktree to continue your work on another branch.
Re: Fossil vs Git
#133Earlier quoted context omitted.
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?
Disk space?
Re: Fossil vs Git
#134Earlier quoted context omitted.
that doesn't scale. I personally prefer a single squashed commit linking to a full discussion in a PR/MR: do a git blame, even if you get a giant hairball commit, you should be able to trace it to a review process (PR/MR) where it was discussed and thoroughly reviewed.
It scales quite well. Linux itself is developed in this way. Or perhaps you think Linux isn't at a large enough scale? (No sarcasm, I know that there projects out there much bigger than Linux.)
How does this work with multiple developers working on the same repo? I'm assuming everyone should work on their own feature branch and send PRs once their branch is done? Should the commits also be tagged by the feature branch they're on? Should the CI approval workflow be run against any combination of commits on the feature branch or against the final HEAD?
Re: Fossil vs Git
#135Re: Fossil vs Git
#136Earlier quoted context omitted.
How do you estimate Fossil's general popularity? Most projects are invisible to you, like in-house projects that never see the light of day. If Fossil is used by 1% of those projects, that's still a lot of projects. How can you tell if Fossil is popular in HN? By my reading, only two people in this thread use it. More than that mention having never heard of it before, or make statements where it's clear they don't re…
Fossil is posted to and discussed on HN all the time. It's a novelty, it differs in design from the popular tools that people actually use in their day-to-day jobs. There's really no reason to think that Fossil is used internally at a rate higher than its public-facing usage. And I've literally never seen a project that uses Fossil aside from Fossil examples.
From https://news.ycombinator.com/from?site=fossil-scm.org there are 20 links to fossil-scm.org in the last 2 years. I manually looked at the last 2 years of submissions with "fossil" in the name and found an additional 4 which were not to fossil-scm.org.
It's over 50% higher for Mercurial. I counted about 30 postings with the name 'Mercurial' over the last two years, of which about 7 were from mercurial-scm.org. I left out some of the obvious duplicates.
You write "I've literally never seen a project that uses Fossil aside from Fossil examples".
How much effort did you put into looking, and would you have recognized one if you did?
After SQLite, the most widely used project which uses Fossil is likely Tcl. http://core.tcl.tk/tcl/wiki?name=Index says it uses Fossil 2.7. For obvious reasons, there is an affinity between Tcl projects and Fossil.
A search for '"This page was generated in" "Fossil"' in DDG finds some non-trivial active projects: https://duckduckgo.com/?q=%22This+page+was+generated+in%22+%... . "Active" means "commits in the last few weeks." For examples:
"MySQL++ is a C++ wrapper for MySQL’s C API" - https://tangentsoft.com/mysqlpp/home
"Jsi is a C (+/-) embeddable JavaScript interpreter" - https://jsish.org/fossil/jsi/doc/tip/www/home.wiki
"Cxxomfort (cxx as in C++, comfort as in comfort) is a small, header-only library that backports various facilities from more recent C++ Standards" - http://ryan.gulix.cl/fossil.cgi/cxxomfort/index
"SquirrelJME is intended to be a Java ME 8 compatible environment for strange and many other devices" - http://multiphasicapps.net/doc/ckout/readme.mkd
Re: Fossil vs Git
#137Earlier quoted context omitted.
Fossil is posted to and discussed on HN all the time. It's a novelty, it differs in design from the popular tools that people actually use in their day-to-day jobs. There's really no reason to think that Fossil is used internally at a rate higher than its public-facing usage. And I've literally never seen a project that uses Fossil aside from Fossil examples.
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.
Re: Fossil vs Git
#138Earlier quoted context omitted.
"Git has no first-class concept of file name changes. Instead it tries to use heuristics to spot renames and sometimes they work and sometimes they won't." Git has the "mv" command. If you "git mv" a file, why would git have to guess or use heuristics to figure out that the file was renamed?
As the Git FAQ [0] says: > Git has a rename command git mv, but that is just for convenience. The effect is indistinguishable from removing the file and adding another with different name and the same content. git diff, merge, and related tools have heuristics for detecting file moves (off by default, turned on with e.g. git diff -M) but they tend to break if a file is both moved and modified in the same commit. [0]…
Re: Fossil vs Git
#139Git: 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?
Sometimes this is fine, but if the history is large enough (like in the case of the Linux kernel), it can start to get out of hand space-wise. If you have a deduplicating filesystem, that can help, but only so much.
Of course, there is a way to use clone which hardlinks the objects.
Re: Fossil vs Git
#140Would you recommend using fossil for Unity3D projects? Needs to exclude certain files and being able to deal with binary files.