diff --git a/dev-log-repeat-solutions.md b/dev-log-repeat-solutions.md index 9775e1f6..386bb4d5 100644 --- a/dev-log-repeat-solutions.md +++ b/dev-log-repeat-solutions.md @@ -49,7 +49,7 @@ modified: 2021-07-20T13:50:23.433Z - 🌰lts: vscode/ide, git/vcs - vscode: monaco-editor + electron, code-server, sourcegraph - codemirror/prosemirror: state + view + commands + transform/ot/collab + virtualized - - version-history: rrweb, diff, format(.fodt) + - version-history: rrweb, diff, format(.fodt), video-but-auto-update - rspack: js plugin; rolldown-wasm - animation: motion(dom/svg) diff --git a/draft-pastebin-pieces.md b/draft-pastebin-pieces.md index 31e5d54d..32b232ba 100644 --- a/draft-pastebin-pieces.md +++ b/draft-pastebin-pieces.md @@ -287,3 +287,6 @@ $if($gt(%totaldiscs%,1),%discnumber%-,)$if($and(%albumartist%,%tracknumber%),$nu - 王安迪 - andywangkingluckii@outlook.com - AnDy.20080313 + +- 唐银生 + - 农业银行 6228 4804 7850 9920 979 diff --git a/lib-editor-app-community-version-history.md b/lib-editor-app-community-version-history.md index 7c74a25b..d4033092 100644 --- a/lib-editor-app-community-version-history.md +++ b/lib-editor-app-community-version-history.md @@ -112,7 +112,35 @@ modified: 2024-07-18T15:52:38.176Z - ## -- ## +- ## ⌛️🎞️ [CodeTour: VS Code extension to record and play guided walkthroughs of codebases | Hacker News _202103](https://news.ycombinator.com/item?id=26488610) +- A killer feature would be doing semantic analysis to attach steps to AST nodes instead of lines. EG a class or function. + - Without this it seems tours could be broken/outdated very quickly in active code bases. +- 💡 IMHO this is much better solved with a literate programming approach where the tour content lives inside the code as comments. Then as code is refactored and changed it's very obvious that the related docs and tour data has to change too. + - some files don't necessarily support comments (e.g. JSON/image) + - Additionally, after speaking with a bunch of folks, there are definitely teams that weren't interested in "polutting" their code with comments + - That said, I totally agree with the value of a literate programming-based solution. But there may also be some nice properties to a "side car" file as well, and so I'm primarily trying to explore how well we could make that work, in a resilient and easy-to-maintain way. We'll see how it goes +- > there are definitely teams that weren't interested in "polutting" their code with comments + - Add an extension feature that toggles (hides/shows) those comments maybe? + +- Not an equivalent of literate programming. Here you can jump to arbitrary files at arbitrary points, in literate programming your code must flow from top to bottom linearly, which is most of the times impossible to achieve. + +- How do CodeTours handle drift as the code base changes? + - They have a GitHub Action to monitor this + +- 🔒 how is user privacy handled? Is data about the repo sent externally? I assume this would primarily be useful for OSS projects and not private or internal/confidential projects? + - When you record a tour, it simply creates a JSON file that can be committed/maintained as part of the associated codebase. Then, when someone takes the tour later, they're simply "reading" that file locally in their editor, and so no data about the codebase is ever sent externally. + +- I'm hoping that some day it'll be possible for my coworkers to follow a CodeTour without installing VS Code. + - That's exactly the issue we had at the office. So someone in our team built https://github.com/doctolib/code-tours-github we use it to help new joiners get into the codebase! + +- CodeLingo’s playbooks are an approach to solve that type of problem https://playbooks.codelingo.io/p + +- 🆚️ This seems really cool but my immediate thought is that it might be pretty fragile compared to just screen recording. + - Create the tour, then screen record playing through it. Two birds one stone. + - 💡 conversely, a screen recording does not allow for easy maintenance as this plugin does with its tours. + +- Does anyone know of any package similar to this for emacs? + - For vim I use the CodeReviewer plugin to capture comments for files. I modified it to use differently named comment files and to jump to the file locations from the comment line. I am planning to include support for hierarchical comments or referring other comment files from within one. Also the problem of tracking code changes or referring to a certain git commit is still there - in clearcase it can be easily done with a reference to the branch, but not sure how to do it in git. - ## [Hey Dropbox, why can't I compare file versions like this? | Hacker News _202003](https://news.ycombinator.com/item?id=22221265) - Am I missing something? This already exists in Google Docs. Much easier to implement when the doc is database-backed (recording every keystroke for OT) vs file-based. diff --git a/lib-excel-app-list-grid-community-formula-engine.md b/lib-excel-app-list-grid-community-formula-engine.md index 8f677bd8..29fd34c8 100644 --- a/lib-excel-app-list-grid-community-formula-engine.md +++ b/lib-excel-app-list-grid-community-formula-engine.md @@ -16,6 +16,28 @@ modified: 2023-11-12T16:48:11.308Z # discuss-formula - ## +- ## + +- ## + +- ## [A Fast Excel Formula Parser and Evaluator | Hacker News _202205](https://news.ycombinator.com/item?id=31365777) +- I’m surprised that Excel formulas have such poor coverage in text editors like NP++ or VSCode. Developing horribly convoluted formulas with nested IF statements in the formula bar is painful, and the PowerQuery editor doesn’t even have syntax highlighting. + +- The lack of decent syntax highlighting, auto-indentation or “IDE mode” instead of the formula bar can be painful. Especially when working with models developed by others. + - On the other hand, you can see it as a feature. It forces you to keep your formulas short, break them down in helper columns and overall make your logic cleaner. + +- In the old Excel with only cell grid references I would agree. However in "new Excel" with LET expressions and LAMBDA it is now possible to write legible and self-documenting code where the lack of decent editing support is becoming a problem. + +- It’s really new but the Advanced Formula Editor tackles this, and goes further. It’s a collaboration between the Excel team and MS’ Cambridge boffins. + +- Python and Pandas > Excel for anything outside of exploratory spreadsheet-y like calculations + +- nothing can compete with Excel in terms of modeling speed and agility. A capable analyst can do miracles with Excel, find other routes to a solution, and then produced model can go to Python/Pandas developer for the processing optimization. + +- bamboo seems interesting but their acquisition by Databricks stopped development on Bamboo last year. + +- Excel uses IEEE 754 double precision which stores up to 17 significant digits but the Excel UI itself only displays up to 15 significant digits. + - ## [Excel formulas in JavaScript | Hacker News_201404](https://news.ycombinator.com/item?id=7638879) - - diff --git a/lib-ide-vscode-community-storage.md b/lib-ide-vscode-community-storage.md index b52b11d7..7a004e60 100644 --- a/lib-ide-vscode-community-storage.md +++ b/lib-ide-vscode-community-storage.md @@ -34,6 +34,15 @@ modified: 2024-12-14T17:28:23.214Z - Tree sitter grammars generate a complete/concrete syntax tree with incremental updates, they necessarily have to be able to represent invalid source text (because users will type it!). - If you're using a tree-sitter grammar as the input to a compiler (which is not what its designed for) you need to write a pass to convert from CST to AST, as you normally would. +# discuss-vscode-web-storage +- ## + +- ## + +- ## [Use `vscode-vfs` (instead of `gitlab-web-ide` ) as Web IDE file system scheme · Issues · GitLab.org / gitlab-web-ide · GitLab _202406](https://gitlab.com/gitlab-org/gitlab-web-ide/-/issues/357) + - Update the Web IDE file scheme to vscode-vfs (from gitlab-web-ide). It looks like this is a hardcoded scheme in a number of VSCode logic (and even extensions). + - VSCode has some built-in logic which suggests that the main virtual file system used in the browser should be `vscode-vfs` . This blocks us from using enableWorkspaceTrust: true + # discuss - ## diff --git a/lib-ide-vscode-community-usage.md b/lib-ide-vscode-community-usage.md index abc2b52e..d0705a89 100644 --- a/lib-ide-vscode-community-usage.md +++ b/lib-ide-vscode-community-usage.md @@ -63,6 +63,32 @@ modified: 2024-08-24T16:52:53.996Z - ## +- ## + +- ## + +- ## + +- ## [I can't stand using VSCode so I wrote my own | Hacker News _202404](https://news.ycombinator.com/item?id=40106157) +- This is the way. Anytime I have had issues with an open source project, creating a PR even if it's not great will often have it taken over, improved and merged. + +- VSCode is still on the top of accessibility, so when you can claim that you work perfectly with a screen reader, you will convince me to switch. + - people often overlook accessibility and other essential features of a modern editor, you telling me that your rudimentary rust editor is faster than vscode? and? people don't use it because it's fast (it's not). + +- One of the benefits of Electron is being able to build the same app for multiple operating systems. When writing GUI app using native OS calls, how does one make sure the code is compatible with all three major operating systems? + - Folks did this plenty prior to Electron, either by using cross-platform GUI toolkits (GTK and Qt both run on Windows, Java's been doing this forever with Swing and JavaFX, etc), or by writing GUIs for multiple toolkits/OSes that work with the same/similar core application logic. + - Electron makes it easier to build cross-platform apps, and certainly cheaper, but it's not like it's the only way to do it. + +- ## [Microsoft is introducing hidden APIs to VS Code only enabled for Copilot? | Hacker News _202410](https://news.ycombinator.com/item?id=41907350) +- I don’t see any problem here. They spend money, effort, time to develop their products. Why do they need to give that products for free to everyone, or even their competitors? + +- I discovered that VSCode has a set of APIs for adding SSH tunneling, and under normal circumstances you must launch vscode with special flags to be able to use them. Somehow their built-in JavaScript debugging extension can use these APIs without any issues. + - And you can hardly find any public information about these APIs. Well, unless someone asks -- As of 2 years ago, they didn't have any plans to "finalize" these APIs, i.e. make them public. You are advised to find other workarounds (which do work). + +- Microsoft has been very clear about their business model of VSCode -- similar to Chromium, the base product is free and you can do whatever you want, but extension marketplace/remote/GitHub Copilot are proprietary. + +- they have a number of "inline completion" APIs standardized as both VSCode APIs and LSP protocol (upcoming). + - ## [Visual Studio Code: Secrets of Regular Expression Search | by Nikhilbaxi | Medium _202309](https://medium.com/@nikhilbaxi3/visual-studio-code-secrets-of-regular-expression-search-71723c2ecbd2) - (.+) : This is used to find the content between the unknown. For example, we need to find where the API call is defined. - `/api/user/${userId}/address/` or `/api/user/123/address/` ; diff --git a/lib-ide-vscode-community-web.md b/lib-ide-vscode-community-web.md new file mode 100644 index 00000000..b5b2f88b --- /dev/null +++ b/lib-ide-vscode-community-web.md @@ -0,0 +1,63 @@ +--- +title: lib-ide-vscode-community-web +tags: [community, vscode, web-ide] +created: 2024-12-31T21:06:59.021Z +modified: 2024-12-31T21:07:14.052Z +--- + +# lib-ide-vscode-community-web + +# guide + +# discuss-stars +- ## + +- ## + +- ## + +- ## +# discuss-internals +- ## + +- ## + +- ## + +- ## +# discuss +- ## + +- ## [Vscode.dev | Hacker News _202110](https://news.ycombinator.com/item?id=28932206) +- >Well, offline VSCode is a glorified browser as well. + - Not really, it may use electron for the front end, but a huge amount of what makes vscode useful and fast is the native binaries that power all of its functionality. +- What are those native binaries? I know that VSCode ships with ripgrep, but that's the limit of my knowledge. Those binaries probably could be compiled to WASM to make VSCode fully run in a browser too. + - The Language Servers that power all of the intellisense and syntax highlighting and stuff are all native code. As are the compilers and everything that make VSCode more than just a text editor. + +- Why bother with all of that when you could just ssh (nee telnet), remote X or VNC sessions to a server? + +- check the discussion about their differences https://github.com/cdr/code-server/discussions/4267 (IMO both are much slower and worse than vscode.dev) + - There is no direct comparison, so unfair to call them slower or worse. Both these services are for running your own private server and for browser IDEs to be thin clients. You can configure the server with your language tooling, build scripts and whatever else. You can also pause and resume your session from a different device (since a majority of business logic is handled by the server). + - vscode.dev runs fully in your web browser, and files are read from local disk. There is nothing in the cloud. So yes it is faster, but serves a different use case. + +- theia has a nodejs server backing its web experience. This vscode.dev is an entirely client side JS application that runs in your browser--there's no backend server beyond something to serve a pile of static JS and html. + +- The blog post says it's using a brand new local file access API only in cutting edge browsers (edge and chrome) so you can access the files on your machine directly from the browser. There is no server upload of anything. + +- Interesting they're using tree-sitter for syntax highlighting. Obviously they can't run LSPs in the browser so this must have been an alternative. + - The article points out that the Typescript/Javascript and Python LSPs run in the browser providing "better" experience than the tree-sitter experiences for languages without browser capable LSPs today. +- They don't use tree-sitter for syntax highlighting unless the extension you're using uses it. By default (and almost everything uses the default) VSCode uses the Textmate syntax highlighting system. + - And there's no reason they can't use the LSP in the browser as long as the actual language servers can run in the browser - pretty easy with most languages these days. + +- Two features missing right away: Terminal and Remote SSH. + - From my understanding, since their vscode uses browser file access api with zero installation, adding terminal seems non-trivial. I have been working on something that solves that: https://tym.so (shameless plug here). I’m trying to build a vscode on the browser that can be connected to any computer with a one line install and has easy multiplayer features. Love to know what you all think about it + +- It's crazy how much the dev tooling space has evolved in just the last few years. VS Code is of course a big part of it, but there are a hundred offshoots providing CI/CD, dev VPS, source control integrations, language tools, static hosting, staging, functions. The next step, IMO, is more clarity. How do all these puzzle pieces fit together, and what is the "ideal" solution for me as an individual developer or a small team to use day-to-day? + +- ## [Visual Studio online available for public preview | Hacker News _201911](https://news.ycombinator.com/item?id=21442088) +- The use case for VSCode Online is the same as any other remote development environment, combine it with deployment workflows and or integrated services like Azure and it practically sells itself. Just like Slack the secret sauce here isn't the service itself, it is how it ties into everything else. +- What other remote development environments exist? I can only think of cloud9. + - Nano/vim/emacs/etc over a remote (SSH) terminal, remote VM, or remote session via other means (e.g. VNC/RDC/etc). People use Visual Studio itself remotely via VMs and RDC. + +- ## [Microsoft’s web-based version of Visual Studio | Hacker News _201911](https://news.ycombinator.com/item?id=21461681) +- Because VSCode is an electron app, meaning that it probably relies on Chromium-only features that they have to find workarounds for in Firefox before things like keyboard shortcuts work. diff --git a/lib-ide-vscode-dev.md b/lib-ide-vscode-dev.md index b98611a3..7ca2e3c9 100644 --- a/lib-ide-vscode-dev.md +++ b/lib-ide-vscode-dev.md @@ -11,6 +11,7 @@ modified: 2024-08-24T16:15:11.456Z - pros - 完善的编辑器和ide功能,包括 editor/workbench/files/search/ext/cmd-palette + - 支持运行在多种环境,如 web-memory, web-node-server, electron - theia is licensed under EPL, not as friendly as vscode/MIT - cons diff --git a/lib-ide-vscode-examples-extensions.md b/lib-ide-vscode-examples-extensions.md index ba4318d5..7483a185 100644 --- a/lib-ide-vscode-examples-extensions.md +++ b/lib-ide-vscode-examples-extensions.md @@ -88,23 +88,57 @@ modified: 2024-08-24T16:17:26.715Z - https://github.com/sekassel-research/vscode-vnc-plugin /202212/ts/archived - This extension adds an embedded vnc viewer to the vs code server instance, which is used by fulib.org projects. -# vscode-browser +# vscode-web - https://github.com/antfu/vscode-browse-lite /ts - Embedded browser in VS Code # extensions -## ext-office +## ext-office/files + +- https://github.com/cweijan/vscode-office /MIT/202412/js + - 让VSCode支持预览PDF, Excel和Word等格式, 并增加markdown所见即所得编辑器 + - 支持预览xlsx, docx, svg, pdf, zip等格式, 后来才增加markdown编辑器 + - 依赖docxjs、sheetjs、vditor(md)、pdfjs + - [Please support PPT/PPTX files _202211](https://github.com/cweijan/vscode-office/issues/166) + - I have done research on this, but due to the complexity of ppt/pptx, it is impossible to display it in js. + - https://github.com/orellabac/vscode-office /202010/js/inactive + - Word: mammoth + - Excel: sheetjs + x-spreadsheet + - md: stackedit + - PDF: pdf.js + - PhotoShop: psd.js + - xmind: xmind-viewer + - Image: lightGallery - https://github.com/janisdd/vscode-edit-csv /MIT/202310/ts - vs code extension to edit csv files with an excel like table ui - If you don't have vs code to hand, you can use the online version at https://edit-csv.net +- https://github.com/mikeebowen/ooxml-validator-vscode /MIT/202412/ts + - A VS Code extension for validating Office Open XML files + - The OOXML Validator validates Office Open XML files (.docx, .docm, .dotm, .dotx, .pptx, .pptm, .potm, .potx, .ppam, .ppsm, .ppsx, .xlsx, .xlsm, .xltm, .xltx, or .xlam) and displays the validation errors found in the xml parts in VSCode and creates an optional CSV or JSON log file of the validation errors. + ## ext-git - https://github.com/MichaelCurrin/auto-commit-msg /ts - A VS Code extension to generate a smart commit message based on file changes - With the explosion of AI tools, you can find alternatives to this extension which use AI - see AI tools +## ext-history + +- https://github.com/microsoft/codetour /MIT/202303/ts/inactive + - VS Code extension that allows you to record and play back guided tours of codebases, directly within the editor + - A "code tour" is simply a series of interactive steps, each of which are associated with a specific directory, or file/line, and include a description of the respective code. + - Tours can either be checked into a repo, to enable sharing with other contributors, or exported to a "tour file", which allows anyone to replay the same tour, without having to clone any code to do it + - Recording Tours: You can create directory steps, selection steps, or content steps in order to add an introductory or intermediate explanations to a tour. + - Re-arranging steps + - Versioning Tours: When you record a tour, you'll be asked which git "ref" to associate it with. + - Behind the scenes, the tour will be written as a JSON file to the `.tours` directory of the current workspace. + - This file is pretty simple and can be hand-edited if you'd like. + - you can manually create tour files, by following the tour schema. + - Maintaining Tours: In order to ensure that your tours stay up-to-date as your codebase evolves, you can install one of the following tasks as part of your CI pipeline, in order to detect "tour drift" in response to PRs/commits/etc. + - [CodeTour: VS Code extension to record and play guided walkthroughs of codebases | Hacker News _202103](https://news.ycombinator.com/item?id=26488610) + ## ext-data - https://github.com/microsoft/vscode-data-wrangler /未开源 diff --git a/lib-utils-codesandbox-community-runtime.md b/lib-utils-codesandbox-community-runtime.md index 58a90bed..9a38c50c 100644 --- a/lib-utils-codesandbox-community-runtime.md +++ b/lib-utils-codesandbox-community-runtime.md @@ -118,11 +118,38 @@ modified: 2024-05-12T17:20:03.132Z - service worker 中监听 fetch 事件当然是可以拦截脚本的请求的,不信你可以试试 - 包括esm加载时的请求都可以被拦截 +# discuss-cloud-env +- ## + +- ## + +- ## [Cloud, why so difficult? (2022) | Hacker News _202306](https://news.ycombinator.com/item?id=36488733) +- Cloud is difficult because it stiched together from fragments of old applications and approaches. + - Cloud will be easy with consistent approach. One or very few languages for everything, from configuring resources, to configuring policies and writing code. + - Cloud will be easy with opinionated tooling. No Dockerfile and supporting of miriads languages. Just file with dependencies and folder with source code. + - Cloud will be easy with opinionated approach to configuration. No need to support PASSWORD env, PASSWORD_FILE env, some secret access service. Only one secure and simple way. + +- +- + +- ## [Cloud desktops aren't as good as you'd think | Hacker News _202210](https://news.ycombinator.com/item?id=33106234) +- Latency for every keystroke, your brain starts to add latency to latency that is not there to compensate for a life lived wearing citrix latency goggles. + +- Nothing beats working directly on a fast but quiet workstation sitting next to my table. + +- With cloud gaming you can stream 4K games at 60FPS, with clarity and quality for fast moving objects. + - Why does remote desktop still shit itself when I move around MS Word with a few pictures? + +- +- + # discuss-runtime-vm - ## - ## +- ## + - ## 👷🏻 I 100% agree with this. We needed an orchestrator that understands VM snapshotting/cloning and can spin up a new VM extremely quickly. - https://x.com/CompuIves/status/1853478202569617647 - We tried different solutions, but ultimately we had to build our own because nothing fit the bill. diff --git a/lib-utils-git-community-alternatives.md b/lib-utils-git-community-alternatives.md new file mode 100644 index 00000000..8df91a4e --- /dev/null +++ b/lib-utils-git-community-alternatives.md @@ -0,0 +1,348 @@ +--- +title: lib-utils-git-community-alternatives +tags: [alternatives, community, git, version-control] +created: 2025-01-01T17:05:39.534Z +modified: 2025-01-01T17:05:58.461Z +--- + +# lib-utils-git-community-alternatives + +# guide + +# discuss-stars +- ## + +- ## + +- ## +# discuss +- ## + +- ## + +- ## +# discuss-github +- ## + +- ## + +- ## + +- ## [Why GitHub won | Hacker News _202409](https://news.ycombinator.com/item?id=41490161) +- > your remote GitHub repo can be located on any machine with an ssh connection + - Technically true, but GitHub provides so many more tools that it's almost silly to do so. + - Aside from the "hub" in GitHub such that it is often the first and only way that some people will look for projects they're interested in, you also get the nice web interface for quick code browsing, issue queues, the ability to add and remove people with a simple GUI rather than SSH key management, wikis, email notifications, and so on and so on. +- They invented "pull requests" and offered (initially minimal) code review tools. This made contributing in the open.much easier, and making small contributions, vastly easier. + - Pull requests predate Git. The kernel developers used them in the Bitkeeper days + +- GitHub won because Git won. It was obvious by the late 00s that some DVCS was going to upend subversion (and more niche VCS like TFS). It ended up a two horse race between Git and Mercurial. GitHub bet on Git. Bitbucket bet on Mercurial. + - GitHub's competitors were too slow to embrace Git. So GitHub dominated developer mindshare. +# discuss-gitlab-gogs-gitea-platform +- ## + +- ## + +- ## [Any GitHub/GitLab alternatives built for non-technical users? : r/git _202101](https://www.reddit.com/r/git/comments/l2ae04/any_githubgitlab_alternatives_built_for/) +- The difficulty, IMO, is that Git works best with plain-text files. But many non-IT (NIT) people are wedded to proprietary file formats like MS-Word. So, merely making Git more intuitive ain't going to help—NITs still won't be able to take advantage of Git. + +- Wikis can provide good collaboration and version control for text, though, and most people should have at least a passing familiarity with the concept by now. + +- I Agree. The answer is something like Confluence. + +- What is your goal / what should this software mainly be used for? (What problem are you trying to solve?) + - If you just need versioning, there are many simple backup or synching programs. + - If you need "forking", there are online collaboration office tools which might be a better fit. + +- Gitea is a lot simpler than GitLab/GitHub and still has the core functionalities. + +- Check out gitbook. + +- ## [Harness launches Gitness, an open-source GitHub competitor | Hacker News _202309](https://news.ycombinator.com/item?id=37598082) +- Codeberg (2019), which was based on Gitea until they forked it into Forgejo (2022). + - Codeberg is a service not a separate software. Just like you wouldn't count salsa.debian.org or framagit.org as separate from GitLab, they are the same with maybe some local customization. + +- How does Gitness differ from already existing open source alternatives, such as Gitlab, Gitea, Gogs, Forgejo, Codeberg, Gitweb? + - Gitness actually launched in 2012 under the name Drone, with a focus on continuous integration. + - So Gitness has a very strong, mature pipeline engine that is also very popular in the Gogs and Gitea community (Gitness is backward compatible with any Drone yaml). + - Of course, this is just our initial launch which is a very important milestone, but we have a lot of feature gaps and a lot of work to do to make our Code Hosting solution a more interesting replacement. Stay tuned. + +- I won't trust Harness with anything open source. It's the same company that killed the open source Drone CI after acquiring it. They changed the license such that you could contribute to it but could not use it if your revenue was more than 1 million USD. They didn't fix bugs that were well known to them because they were working on the enterprise version of it. + +- How does this compare to e.g. Forgejo, Gitea, Gogs, self-hosted GitLab, or other alternatives? + - Forgejo in particular has self-hosted actions runners that can be registered offline, and the runners themselves can be given labels and execute most existing GitHub actions (in fact, the yaml format they use is intentionally meant to be compatible with GitHub actions). + - While the Pipelines UI looks nice, it hides all the very real details of deployment (and configuration) in a variety of environments. This is one thing Forgejo does well compared to e.g. Gitea for CI/CD, thanks to being very flexible in configuring runner secrets, registering runners, and so on. + - The reason I am emphasizing CI/CD is because hosting code and a bug tracker is only one small aspect of GitHub IMO. The real big things are its popularity and GitHub Actions. It's not enough for many people (and businesses) to simply host code anymore. Many now expect commits pushed to certain branches to execute a variety of workflows -- from unit tests to full-on Kubernetes deployments. + +- They should host a demo instance like Gitea does. + +- Interestingly it looks like this is partly a fork of Gitea (or at least, incorporates large amounts of code from Gitea) + - It is largely based on the existing Drone repository, but for Git capabilities we used the Gitea fork of https://github.com/gogs/git-module + +- looks more complicated than forgeo/gitea . gitea already servers all github needs for us + +- ## [Four years of SourceHut (SourceHut is a open source github alternative) : r/linux _202211](https://www.reddit.com/r/linux/comments/ywbrtc/four_years_of_sourcehut_sourcehut_is_a_open/) +- if only sourcehut was in any way user friendly. making pull requests and looking for issues is such a pain + - It's email-based, not PR-based. Although devs use git-request-pull instead of git-send-email. + - Also, issues go to the https://todo.sr.ht page. It's just that some devs don't use that. + +- ## [Gitlab like server in nodejs _201702](https://github.com/open-source-ideas/ideas/issues/29) +- I created a basic ssh server that can now clone and push changes. Still needs work on public key auth. Currently using password authentication. + +- I feel like Gitea already fills this niche. GitLab supports many features. It's arguable the most complete of the OSS Git front end web apps. Gitea lacks many of its features, but it's considered extremely lightweight, enough so to run well on a Raspberry Pi. + +- We need a decentralized open-source alternative, not Gitea or Gogs. + +- ## [Does anyone know of a Node.js alternative to GitLab? : r/node _201309](https://www.reddit.com/r/node/comments/1n9byh/does_anyone_know_of_a_nodejs_alternative_to_gitlab/) +- I'm pretty sure nothing like that exists. +- Well Github was originally written on top of a library called Grit which allowed for Ruby to interact with repos. Theyce since moved on to use a C library called libgit. It's possible to write a Node plugin that will interact with libgit, of one doesnt already exist. This would be my first move if I were in your shoes. Once you have a javascript implementation of something like Grit, you'll be able to manipulate and pull information from repos. + +- ## [OneDev - Selfhosted open source alternative to GitHub/GitLab : r/selfhosted _202108](https://www.reddit.com/r/selfhosted/comments/p1fikz/selfhosted_open_source_alternative_to_githubgitlab/) +- Gitea is certainly a really nice project. + - We even used its predecessor gogs for some time, before switching to OneDev. + - The main reason is lacking of functionality such as pull request approval, reviewer auto-assignment based on contribution history, easy symbol navigation while reviewing pull request, selecting any diff/code to start discussion, real-time preview when authoring markdown, customizable issue field and state etc. + +- Gogs/Gitea is perfect for personal usage. But for teams with dozens/hundreds of people, some solid features need to exist to be efficient. This is what we built into OneDev. + +- ## [Re: [jgit-dev] Introducing OneDev - an open source git server _201901](https://www.eclipse.org/lists/jgit-dev/msg03748.html) + - Looking at https://github.com/theonedev/onedev/blob/master/core/pom.xml, it appears this is a web interface that uses JGit for Git support. + +- Yes it is using JGit for most operations. JGit API is very well designed and is a joy to use. + - The performance is very good, except for long operations such as full clone. + - So for pull/push I am calling native git, but for other operations which may need to be executed several times during a request I am using JGit which is much faster thanks for the in-process cache. +# discuss-git-alternatives 🆚️ +- ## + +- ## [Steve's Jujutsu Tutorial | Hacker News _202410](https://news.ycombinator.com/item?id=41881204) +- The auto committing behavior is a bit weird at first, but now I don't want to go back to git. + +- The holy grail of a stacked diff workflow would be making multiple Github PRs each made against the previous branch instead of trunk, and then updating the branch that's closest to trunk and rebasing all of the children PRs without having to force push into any of them. + - Git and Github do not support this workflow directly, and this creates space for all the other tools. + - Jujutsu comes close to supporting this workflow directly, without having to provide any specialized utilities that mention "stacked diffs" at all. + +- ## 🧩 [Jujutsu: A Git-compatible DVCS that is both simple and powerful | Hacker News _202308](https://news.ycombinator.com/item?id=36952796) + - Jujutsu started as author's personal project and now author's full-time project at Google. It's presented at Git Merge 2022 + +- There's no longer a time to think about what's being committed, because all file changes automatically amend the working copy commit. + - What happens if you accidentally save a file with some sort of secret that gets sucked in? + +- For 90% of git users 90% of the time, the staging area is an inconvenience that adds an extra step. + +- If you're storing 1TB of binary files in git, you're just doing it wrong anyways. You have a bunch of other tools and capabilities for doing this in a way that doesn't make your repository nightmarishly stupid to deal with because of its size. +- Nexus, Artifactory, Packages (deb, rpm, nix), Cache, GitHub Releases... There are so many places you can grab a signed binary from that are just outright better for the health of your repo, and will respect your developers time. +- The issue is not limited to archives, artifacts, and packaging. Game projects, for example, have large directories with many binary assets which need to be change-controlled. Artifact repositories address distribution, in a way, but don't generally support change control much if at all. (And yeah, git's historically a poor choice for this – so you may see companies sticking with Perforce or other non-distributed solutions.) + +- Why do you want such big files in a git repo? + - The point is to have an easy way to distribute code as data. This is important for many areas, such as training neural networks (code with proper seeds can ensure the weights output by training), various applications in basic physics, database creation via ETL, etc. + +- We were storing binary files separately via Maven for Java projects for almost 20 years now. + - This was done with SVN projects. Keeping the blobs out of your source repos has been the preferred way for a long time. + - The only folks who seem to want to do this are game developers, and they are generally not people you would want to emulate. + +- Currently, `git bisect` works best if every commit is buildable and runnable, in order that any commit can be automatically tested for the presence of the bug, to narrow down the problem commit as quickly as possible. +- Yeah git bisect is great. And CRDTs on their own probably won’t preserve enough information to allow bisecting to happen - since we don’t know which points in time have working builds. + - One approach to preserve the ability to bisect would be to allow users to periodically mark points in time with “commits” if they want. The commits wouldn’t be used for synchronisation or merging (since we have the crdt information for that). Instead, they could act semantically much more like anonymous git tags. But they would still be useful as landmarks to mark working builds and milestones. And for git bisect. We could give them associated commit logs. (“Got feature X working”, “Release 1.0.5”, etc). + +- +- +- + +- ## [Darcs - Another open source version control system | Hacker News _201205](https://news.ycombinator.com/item?id=3947103) +- The primary pull of the "patch theory" is that it will allow you to share code more easily between different "patch sets" (branches / forks). + - The reality of software projects means that you can't automate such a process except in the most trivial cases, and other VCSs handle the trivial cases already. + - By contrast, Git/SVN/Hg folk think about snapshots of development. So it's a different paradigm. + +- +- +- + +- ## 要想实现 Google 代码管理方案,目前开源解决方案只有 Meta 的 Sapling ,但是对 Git 兼容不太好; +- https://x.com/genedna/status/1797927349624901967 + - 我在做一个 Git 兼容开源方案 Mega, 实现确实很复杂,但是慢慢能看到雏形,争取今年能 Release 一个版本。 +- FYI:我们正在给 Sapling 加 .git 的支持,这样用户可以既可以用 sl 命令也可以用 git 命令 + - Mega is an unofficial open source implementation of Google Piper. + +- ## [为什么很多大企业都在用收费的perforce而不是免费的svn或者git? - 知乎](https://www.zhihu.com/question/23930380) +- 主要还是SVN和GIT都对二进制文件支持很差. GITHUB还特别针对大型文件做了GIT-LFS插件用来支持这种超大文件. + - 而大型研发公司. 特别是做3D软件的. 分分钟容量爆棚 + +- 之前不觉得P4有多屌,直到在P4里面创建了有分支功能的stream库,我只能说实在太好用了,一切都是那么清晰。 + - 问了一下,初创公司,每个用户授权大概8000+ + +- 好像是从15年版本后开始的,还有个1000次提交次数的限制,需要扩展人数可以联系我 + +- ## 🌵 [Pijul is a free and open source (GPL2) distributed version control system | Hacker News _202402](https://news.ycombinator.com/item?id=39452543) +- Do you know of any FOSS alternatives that handle that stuff better (specifically binary asset handling and permissions)? + - Pijul does binary files natively, actually. Permissions aren't hard to add, if anybody had a real-world case I'd be happy to help. + +- the places where I've seen people leverage the folder-level permissions in Perforce (in the games industry) would be like: a contractor that provides art would only have access to the portions of the project that relate to the art they're working on but not the code; translators might have read access on one directory and write access on another directory. + - In academic settings I've seen Perforce used such that an instructor has read-write access on a directory and students have read-only access on the directory, and then each student has a subdirectory where they have read-write access and everyone else has read access, so that everyone can play each other's games. + - You can do stuff like this in git with submodules but it's somewhat complicated and difficult to teach to non-programmers. + - The mathematical/theoretical foundations are clear, but the target audience is unclear, so I'm not sure if these are use-cases that you consider to be within the project's scope or not; just sharing how I've seen the permissions models used in the games industry. + +- some indies use Subversion, but Perforce is the industry standard. + +- Git compatibility is a great way around this problem. I have been enjoying Jujutsu lately. +- Supporting conversion with some lossy tendencies is a good idea, but maintaining compatibility will stifle innovation as al bugs & design decisions cannot be fundamentally worked around. + - Adjacent, I heard folks praising Forgejo for its Actions & Microsoft GitHub compatibility, but that means you are still left with the same YAML spaghetti and its other limitations. What would have been nice is something better for CI--something that prompts the project to want to switch to get a better experience. + - As such, while I agree with the moral reasons to switch to non-proprietary software, the reason for switching is philosophical, not philosophical + technical. I feel being a wrapper around Git or Git compatibility will likely fall in this category rather than being more compelling. +- Not really. The real innovation of a lot of these alternative DVCS systems is that they free the state of the source from being dependent on the history that got you there. Such that applying patches A & B in that order is the same as applying B' & A' -- it results in the same tree. Git, on the other hand, hashes the actual list of changes to the state identifier, which is why rebasing results in a different git hash id. + - So long as you require git compatibility, you're kinda stuck with git's view of what history looks like. Which is rather the point. +- jj is not patch based, like pijul, but snapshots, like git. + - A sibling commentor points out the change id stored by jj: it is true that at the moment, this isn't really exportable to git in a native way. However, there is a path forward here, and it may come to pass. Until then, systems like Gerrit or Phabricator work better with jj than systems like GitHub. +- Jujutsu uses change IDs, which are an abstraction over commit IDs, that are stable over operations like rebasing. + +- So Pijul is patch-based. And not in the boring implementation-sense of storing changes as a series of patches. In the interesting sense that patches can be ordered in more arbitrary ways. + - On the other hand Git is snapshot-based. And Git was built for the Linux Kernel (specifically from the perspective of the lead maintainer). +- My understanding is that a big part of the reason that Git is snapshot based is for reliability and for ease of checkout -- being snapshot based means Git doesn't need to replay commits every time you check things out. + - That likely comes with some downsides (cherry-picking does come to mind, yes), but also seems like some serious upsides, one of the biggest one being that simplicity. It's relatively easy for me to reason about what Git is doing under the hood. + - I like that I'm seeing that Pijul's patch operations are associative, I like at first glance what I'm seeing it say about merges, but it's not making it clear to me what the downsides are. +- There's no reason you can't cache tree snapshots in a pijul/darcs setting. That's just an implementation detail. The difference is more in how a rebase or merge operation works internally, and how essential the particular history is to the current workplace state. + +- 🆚 Pijul has a number of stated strengths over Git, and looks like the version history is implemented as a CRDT from my first impression. Some of the statements make me wonder how many conflicts occur in real use. If they are equal to or less than the number it produces, great. If more than what Git produces, that's a barrier to adoption, as merge conflicts are one of the biggest pains when using Git. + - 🐛 Git compatibility is a key missing feature. Git had this with Subversion, and I think it's a big reason why Git won over many of the Subversion crowd. + +- I'm watching this (and Jujitsu, Sapling, etc.) with interest, but I wish there was more focus on Git's real weak areas. Yes it sometimes makes merge conflicts more difficult than it could, but you can generally deal with that. +- 🐛 The bigger problems are: + * Poor support for large/binary files. LFS is bare-minimum proof of concept. + * Poor support for large projects. Big monorepo support is definitely getting better thanks to Microsoft. Submodules are a disaster though. + - The basic premise of Pijul is that the way they model changes leads to better merges, fewer conflicts, and (crucially) no cases of bad merges. Git can complete merges and do it incorrectly +- Large/binary files: Pijul splits patches into operations + contents. You can download a patch saying "I added 1Tb there" without downloading any single byte of the 1Tb. No need to add any extra feature. + - Large projects: Pijul solves that easily using commutativity, you can work on partial repos natively, and your changes will commute with changes on other parts of the monorepo. + +- Just like how Sapling is compatible with GitHub, I'd love to see Pijul being compatible with GitHub wrt creating at least a read-only mirror. +- Is sapling compatible? It gets rid of your .git directory. + - It's network compatible in that you can clone, pull, push, etc with a github repo. + +- All version control tools have the same problem since AFAIK none of them care about the semantics of the program being version-controlled (except Unison). + +- 🆚️ IIUC, Pijul has all the good parts of Darcs, with the exponential merge issue resolved. + +- Does Pijul handle branches better than Darcs? I _love_ using Darcs but I had to stop because there was no good way for my teammates to see my new branches (really separate repos) unless I told them myself. + - pijul fork. There you go, I wrote an entire key-value store just to get that to work. It turned out to be faster than all others, but that wasn't intentional. +# discuss-fossil +- ## + +- ## + +- ## 🔁⚖️ [The Fossil Sync Protocol | Hacker News _202402](https://news.ycombinator.com/item?id=39464938) +- The problem with single file formats is they don't play nicely with file sync tools in what I'd call "common" scenarios. + - Due to the way it's laid out, a git bare repository will work quite well with a per-file syncing system because references are stored as files pointing at the hashed object store. + - So the worst you can do even without central coordination is have a reference conflict. I'm sure bad things can happen, but for the purposes of "keeping repos synced via syncthing" it works well enough (note: this is different to trying to keep a working repository synced, which I wouldn't recommend). + +- Since it uses SQLite under the hood, Fossil as a version control system might be able to scale much more gracefully than git for huge monorepos. I think about this often but haven't found a way to effectively use this knowledge yet, since I haven't worked in a giant monorepo shop yet, nor have I found any third parties talking about their experience with this. +- 🐛 They tried using Fossil for netbsd (and may still use it for some things, I'm not sure). Fossil was not designed for large repositories + - [Fossil Forum: Fossil and large repos? _20200908](https://fossil-scm.org/forum/forumpost/5ad122663cbae98f) + - It could be optimized for that case, but since there doesn't seem to be a lot of interest, I don't know that anyone is going to do the work. + +- Microsoft uses git for Windows repository pretty successfully. It started with custom VFS implementation and fork of git but by now everthing is upstreamed and VFS is not used anymore. + - Git original implementation did not scale to huge sizes. Needed specific development work to change assumptions. Presumably similar design improvements could change fossil. + +- I love the concept of Fossil being in SQLite, but there's a reason that Mercurial invented revlogs and Git tries to keep related objects close to each other in packfiles. Sometimes, you really do need a dedicated file format optimized for specific use cases. I'm completely unsurprised OpenBSD wasn't able to pull this off. + +- For a large monorepo network filesystem approach is inevitable. Every local storage approach has limits and breaks down eventually. + +- > The "bag of artifacts" data model used by Fossil is apparently an implementation of a particular Conflict-Free Replicated Datatype (CRDT) called a "G-Set" or "Grow-only Set". + - Isn’t this just by virtue of content addressing objects? In that sense Git’s odb is also a G-set. +- If you look at the definition of CRDTS, it seems trivial that all distributed scms must satisfy CRDT properties. Some observations are trivial once you think about it, but worth saying to connect to different audiences with different interests or backgrounds. I wouldn't be surprised if they added this because they got the question many times. The rest of the paragraph makes clear that they did not develop fossil in the context of CRDTs, and nothing in the rest of the document depends on this observation. + +- 🤔 Is this, or could this be modified to be, able to sync an sqlite database (or really the data it contains) between devices? I'm aware of other ways to do this but if there was an internal sqlite way to do this... + - No, this protocol doesn't deal with SQLite. In fact, SQLite in Fossil is just an implementation detail, the design doesn't depend on it. + +- ## [Fossil | Hacker News_202203](https://news.ycombinator.com/item?id=30815693) +- Git's 'killer-feature' by now is simply its ubiquity + - for Fossil's this could be claimed as a single binary that does it all. + - Just download the binary, and you've got the ubiquitous set of project-related facilities: VCS/tickets/docs/wiki/team/forum/chat with simple aporoach to sync and self-host. + +- It sounds to me that people are split on whether or not SCM should include things like issues and wikis directly, or let others solve it. + - Considering this is the largest point between fossil and git that I can see, maybe we should just make it so git has the capability to expose an extension API for plugging additional capabilities like this in. + - Then we could probably all use git and just be happy. You could theoretically use fossil's issues and wikis with git. + +- It's pretty much Gitea in a single SQLite file (Wiki, tickets, version control, etc.). It's weird, but you can edit all of these things off-line and then sync everything back. fossil ui hosting the server for my docs locally, and from my home server is super useful and easy. + +- Issues and pull requests don't get replicated by git. If github goes down, you can't interact with issues. If github ever turns evil, or you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations. + - Git is a distributed, replicated data format. Why are issues fully centralized? Its bizarre + - Fossil is far from perfect, but I think putting the issues and stuff into the repository itself is brilliant. +- It is brilliant to integrate things with the decentralized source control itself +- But despite its brilliance it's not always the right approach. + - It's very easy and reasonable to want more than what is realistic for something deeply integrated with the source code itself to provide, if only for inherent conflicts of desire, let alone any question of manpower. + - There are very good reasons to have entirely separate (and even multiple-of-kind partially overlapping/integrating/cross-referencing) systems for source code management, issue tracking, code review, forums, IM communication, wikis, public websites, docs (of whatever kinds and types for various audiences and authors, or public or not, or team-level spikes or plannings or retrospectives)... + - One aspect of Fossil I found weak was its user capabilities (no custom user categories alone is a deal breaker for so many things) but flaws in the execution of a fully integrated thing isn't really my point, my point here again is just that full integration despite its overlooked benefits and brilliance when applied to certain things is still not necessarily the right choice for something. + +- My favourite thing about fossil is that the repo is a single SQLite database file so it’s extremely to just back it up or keep the repo in cloud storage. With Git I’ve always had problems with conflicts in the .git directory which messes things up, but fossil is a single file so it backs up to the cloud wonderfully. + +- I'm curious how others do **code review** in fossil? It's something that GitHub is quite good at in my opinion; raising pull requests, having pre-merge checks, commenting on individual lines of changes, etc etc is all useful. It's something I can't see how to do in fossil. + +- I am not sold on the wiki and issue tracker. What would be a killer feature is a web UI interface to fossil commands like sublime merge for git. + +- One thing that has prevented me from trying out fossil is there is no squash. The team has a principled stand on not having it. +- The author of Fossil considers rebase harmful, and because of that, it wasn't implemented + - Fossil has private branches which can serve the same purpose. When you merge a private branch it looks just a single commit, similar to a squashed merge. + +- ## [Fossil | Hacker News_202009](https://news.ycombinator.com/item?id=24643200) +- having issue tracking in the repo prevents lock-in of that data - in the way that the github platform works, for example. + +- I use fossil mostly as a Customer/Project KB/Documentation tool, when a new project starts i have all the documentation, code snippets/examples in one single file, when the project is finished, i have to give one sqlite.db file over to the customer and that's it. LOVE IT, a really great tool! + +- Would like to see a SCM that: + - handles large files effectively (build artifacts, 10-40GiBs each, and other binary dependencies) + - partial checkout of the repo/view + - git style operations (have stage area, can stage parts of a file, can stash changes and reapply later, cherry pick) + - can view the history of an individual file (support file relocation) + - access control on individual files, and partial review of the repository (views are "granted" to developers) + - good tooling + - immutable when it makes sense (e.g. you cannot changed a published commit) + - works offline (if possible) + - large mono repo +- I evaluated git annex and git lfs, and finally chosen Perforce, mainly for its large file handling, view for each developer and ACL, but the lack of flexibility makes me don't want to commit, and every time I do a merge, I say to myself, "uuh, this again". The other thing it lacks is the "ease of mind", with git, everything is checksummed, if the content changes, it will be noticed by git, with Perforce, you have to tell it you want to edit it. + +- There are several bug tracking systems that store their data inside the repository (and as a result, branch / merge / push / pull automatically) -- including the venerable "vi bugs.txt" system which works surprisingly well from experience. + - What fossil brings that those systems don't is indeed the network effect as you pointed out. It's integrated with the web frontend, and is thus used by everyone using fossil and fossil's bug tracking, based on experience with cvstrac, is low ceremony, easy to use and reasonably effective -- even more than "vi bugs.txt" which sets a remarkably low ceremony bar. + +- ## [Fossil – Simple, high-reliability, distributed software configuration management | Hacker News_201412](https://news.ycombinator.com/item?id=8697028) + +- Fossil is version control software with "embedded" wiki and issue tracker, while Trac is a wiki and issue tracker which can, optionally, interface with one or more external vcs systems. + - Fossil stores the wiki and issue data in the repository itself (SQLite), while Trac stores it in an external database (PostgreSQL, MySQL etc.. SQLite would probably work too!). + +- ## [Show HN: Grit – a multitree-based personal task manager | Hacker News_202104](https://news.ycombinator.com/item?id=26673221) +- What's the difference between a dag and a multitree? + - prevents diamond shapes + - An earlier version of the program actually used DAGs, but I found it a little underconstrained. I got pretty excited when I discovered multitrees, as it seemed to be exactly what I needed the whole time. +- Precisely; a multi-tree has a unique path between two nodes. + - On the same note, I wonder what is the relation between dags/multitrees and semilattices. They seem to be very similar concepts afaict. + +- 🤔 How is the data stored? Would it be difficult to sync among different machines? + - Just SQLite - two tables, one for the nodes, one for edges + some fancy constraints and queries. + - As for the syncing, that would be really nice, but I haven't come up with an elegant way to do it yet. Suggestions welcome, if anyone has ideas! +- git. The right storage backend is either git, or a git-like Merkle tree. This is small data. Individual files for objects are fine. Compacting is better, but not critical. + - sqlite is the wrong tool for the job, beyond an initial prototype. git and hg figured this stuff out decades ago. +- Fossil would disagree that SQLite is somehow wrong for this use-case. + - Fossil does seems to have issues when the VCS grows into many many gigabytes of data, like the entire OpenBSD source tree didn't work out very well in Fossil, but the chances of a personal task manager ever growing that size is slim to none I would imagine. + +- I use a flat text file with exactly this structure, just indenting when I need a new layer. + - this supports a slightly more interesting structure than an indented text file: it's actually a DAG where large subgraphs are trees. This allows links between different nodes. That's not possible in an indented text file. + +- TiddlyWiki uses a similar data model for table of contents by default and I love it! I think the multitree constraint is a good idea over a general DAG. + +- ## [Why I'm using Fossil SCM instead of other source control systems (2016) | Hacker News_202206](https://news.ycombinator.com/item?id=31634560) +- I’m just waiting for the next VCS that brings significant changes. We’d absolutely switch over if there was some feature we wouldn’t get elsewhere. But it’d need a couple of months/years of sustained advocacy. + - The next big thing will be semantic code versioning. I.e. a tool that **understands language syntax and can track when a symbol is changed**. + - There are already experiments in this area, but I don't think any are ready for mass adoption yet. + - The fact that it's 2022 and we're still working with red/green line-based diffs is absurd. Our tools should be smarter and we shouldn't have to handhold them as much as we do with Git. It wouldn't surprise me if the next big VCS used ML to track code changes and resolve conflicts. I personally can't wait. + +- Feature for feature Fossil is more like a competitor to Github or gitlab. + - Basically it is a SCM based on sqlite that is a lightweight version of those websites offer. + - To add some detail here. The features it offers (tickets, wiki, chat, forums, etc) are stored within the repo, unlike github or gitlab where those things may be separate. + - Basically, if you have the repo and the fossil binary you have everything. Is this better? I never saw a lot of advantages in my style of work, but i could see this being huge for someone who has intermittent connectivity. Or maybe someone who wants to use the ticket tracking, etc without setting up a separate server or public instance. + - I just love that fossil exists and there is a diversity of opinion on how things can work. + +- Fossil came out in a time when your options were basically CVS, SVN, or something commercial like Perforce. + - Git is an innovation that came out around 2005 (A year before Fossil), and it took a few years to get some traction, but holy moly are either of these better than what came before. + +- I suppose a competitor could also have some kind of git compatibility shim built in to ease the adoption. + - Fossil does let you import and export git I think. Fossil just has the wiki and issues on its side + +- I hear a lot of larger teams insist on squash commits for PRs. Fossil isn't a fan of squashing. + +- Would the wiki part of fossil be a good static site generator? + - Not in the general case, no. Fossil-generated wiki/markdown output expect to be browsed within the context of a fossil repository, and will generate links accordingly. + - There might be very limited use cases where it would work reasonably well, but not generically. e.g. adding a link to a local file or another wiki page will not work if the output is browsed from outside of a fossil repo instance. diff --git a/lib-utils-git-community-issues.md b/lib-utils-git-community-issues.md new file mode 100644 index 00000000..9125a206 --- /dev/null +++ b/lib-utils-git-community-issues.md @@ -0,0 +1,42 @@ +--- +title: lib-utils-git-community-issues +tags: [community, git, issues] +created: 2025-01-01T17:09:32.810Z +modified: 2025-01-01T17:09:51.075Z +--- + +# lib-utils-git-community-issues + +# guide + +# discuss-stars +- ## + +- ## + +- ## +# disccuss-not-yet 🐛 +- ## + +- ## [Git Status Takes a Long Time to Complete - Stack Overflow](https://stackoverflow.com/questions/1183769/git-status-takes-a-long-time-to-complete) +- For me, the slowness was due to having a lot of untracked files (temporary and output files from scripts.) Running `git status -uno` , which excludes the untracked files, ran much faster, and meets my requirements + +- ## [Ways to improve git status performance - Stack Overflow](https://stackoverflow.com/questions/4994772/ways-to-improve-git-status-performance) +- To be more precise, git depends on the efficiency of the lstat(2) system call, so tweaking your client’s “attribute cache timeout” might do the trick. + - The manual for git-update-index — essentially a manual mode for git-status — describes what you can do to alleviate this, by using the --assume-unchanged flag to suppress its normal behavior and manually update the paths that you have changed. You might even program your editor to unset this flag every time you save a file. +- 👣 The alternative, as you suggest, is to reduce the size of your checkout (the size of the packfiles doesn’t really come into play here). The options are a sparse checkout, submodules, or Google’s repo tool. + +- git config --global core.preloadIndex true + - This is now enabled by default already. +# discuss-done +- ## + +- ## + +- ## +# discuss +- ## + +- ## + +- ## diff --git a/lib-utils-git-community-storage.md b/lib-utils-git-community-storage.md new file mode 100644 index 00000000..8dd49b6a --- /dev/null +++ b/lib-utils-git-community-storage.md @@ -0,0 +1,183 @@ +--- +title: lib-utils-git-community-storage +tags: [community, git, storage, vfs] +created: 2025-01-01T16:02:49.007Z +modified: 2025-01-01T16:03:02.565Z +--- + +# lib-utils-git-community-storage + +# guide + +# discuss-stars +- ## + +- ## + +- ## +# discuss-git-fs/web +- ## + +- ## + +- ## [Show HN: Hubfs – File System for GitHub | Hacker News _202203](https://news.ycombinator.com/item?id=30653916) + - HUBFS is a file system for GitHub and Git. Git repositories and their contents are represented as regular directories and files and are accessible by any application, without the application having any knowledge that it is really accessing a remote Git repository. + - The repositories are writable and allow editing files and running build operations. + +- If you build your software to operate on a POSIX-y file system, you can support anything that shows up as a file system. For example: A local working tree of files, an NFS share, or now a remote git repository. + +- I've often thought of using git/github as a document store to replace google drive. I might experiment with this and rsync to see if that makes it possible. + +- Any plans to add support for gists to Hubfs? + - Gists are just repos under the hood, it should work natively. + +- I don't think the filtering they mention for security actually works? Anybody who clones a repo on GitHub can make their own commits appear under the original org url when accessed by ref. +# discuss-git-db +- ## + +- ## + +- ## 🔥 [Git as a NoSql Database (2016) | Hacker News_202104](https://news.ycombinator.com/item?id=26703808) +- In almost every database-backed application I've ever built someone, at some point, inevitable asks for the ability to see what changes were made when and by whom. My current preferred strategy for dealing with this (at least for any table smaller than a few GBs) is to dump the entire table contents to a git repository on a schedule. + +- I store all my dates in sql as text in iso format so I can easily sort them + - Strong SQLite vibes... (SQLite doesn't have a date format, it has builtin functions that accept ISO format text or unix timestamps) +- Why is this bad? + - Sql databases usually come with their own date types that are implemented with integers behind the curtains. They take up less space and are easier to sort than text fields. + +- Why not have a history table and use SQL triggers to insert the new data as JSON everytime someone changes something? + - Indeed. I have on multiple occasions written scripts to automatically generate the triggers and audit tables + +- Git annex is pretty flexible, more of a framework for storing large files in git than a basic sync utility. ("Large" meaning larger than you'd want to directly commit to git.) If you're running Git Annex Assistant, it does pretty much work as basic file sync of a directory. But you can also use it with normal git commits, like you would Git LFS. Or as a file repository as chubot suggested. The flexibility makes it a little difficult to get started. + +- Isn't the problem attempting to be solved here solved by event sourcing? Which lets you 're-create' your changes and is - ultimately- suppose to allow you effectively log each change in such a way its re-playable backwards and forwards + - Kind of, but there’s more to it. “Event sourcing” is the pattern being implemented by git’s immutable object database, but there’s also all the hashing and reference management. + +- +- +- +- +- +- + +- ## 🌵🔥 [GitDB, a distributed embeddable database on top of Git | Hacker News_202207](https://news.ycombinator.com/item?id=31987240) +- version control in general turns out to be highly applicable in many areas far beyond source code. I think it's still under-utilized. + - Yes, it's extremely common to see applications which need a datastore to end up needing lots of version control type features later on, which end up implemented ad-hoc over a general database. +- Git is an abstraction over file trees (or even more generally just chunks of data), and it turns out a ton of problems in software are easily modeled and dealt with as files in a tree. + - Lots of problems in software are easily modeled as ordered lists, but that doesn't mean linked lists are the right tool for accomplishing that. + +- GitDB doesn't handle merge conflicts, so I'm not convinced it would handle multiple clients well. The It's again marked as something they might do in the future someday. I suspect this is pretty fragile. (Note: I was _not_ claiming litestream would do such a thing. Just replication.) + +- You can already store and sync issues in git repo metadata, check out git-bug: https://github.com/MichaelMure/git-bug + +- How does merging work? Would it even be acceptable to allow automatic merging in all types of application? + - To be honest, I would be completely fine with a use case that offloads conflict prevention to the application. + +- ## [How to implement git-like "branching" on a MongoDB database in Node.js - Stack Overflow](https://stackoverflow.com/questions/64635567/how-to-implement-git-like-branching-on-a-mongodb-database-in-node-js) +- I think you are diving into the world of temporal data so it would probably help a lot to start drawing timelines. + +- ## [Does git use databases? - Quora](https://www.quora.com/Does-git-use-databases) +- Git stores everything inside objects found inside .git directory. +- All the references (40 characters hash) pointing to those references are stored inside refs directory. +- git treats files and directories in 3 stages: your normal files/directories, staging area, committed area(repo). + +- ## [Is there a better database than Git (with serializable, immutable, versioned trees)? - Stack Overflow](https://stackoverflow.com/questions/7152276/is-there-a-better-database-than-git-with-serializable-immutable-versioned-tre) +- Datomic provides a persistent data storage and a built-in time notion. + +- Although the index/working copy parts of git can be separated out easily enough, git is not designed for merges or commits at the rate of thousands per second on a single machine. The core code is not even threadsafe, for the most part. You will likely need to create some new system for your data (you can still use git for the code, of course, and can also look into generating git commits to represent your data when necessary, etc). +- So libgit2 isn't thread-safe? It would seem that Git would be inherently thread-safe considering it's data structure + - Nope! It has cache structures, etc, that are not thread-safe. The core git code was only designed to run in a single-threaded manner as command line tools, after all. + +- [Git: the NoSQL Database - Speaker Deck](https://speakerdeck.com/bkeepers/git-the-nosql-database) +# discuss +- ## + +- ## + +- ## + +- ## [Gitfs: Version Controlled File System | Hacker News _202108](https://news.ycombinator.com/item?id=28263356) +- To be clear on what this is, it allows you to mount a git repo and use writes to the filesystem to autocommit and push to the remote, effectively using git and a server to synchronize directories between remote hosts. + - That is not the same thing I would think of as a version-controlled filesystem. That would be something more like the ClearCase MultiVersion Filesystem, which allows you to define versioned views of an entire filesystem. + +- I expected it to be closer to Microsoft's GVFS + - There, they used a filesystem interface to speed up checkouts for large repositories. +- VFS for Git was superceded by https://github.com/microsoft/scalar and then many of the features were merged into mainline git, so what is left now is a thin shell around git features in the form of MS's forked git binary +- VFS for Git solves the issue of having gigantic bloated monorepos used by thousands of devs, making sure user efficiently downloads only what is needed for him. + +- NixOS can also move between system generations seamlessly. The approach is entirely different though, the system is fully defined by its config files and will be recreated from scratch each time it is changed (except /home and /var, mostly). + +- It's different from git-annex in that it's using git itself (git-annex just uses git to track metadata/hash to facilitate large files), but there's a similarity to git-annex's 'Git-annex Assistant' in how it "any subsequent changes made to the files will be automatically committed to the remote". + +- ## [Microsoft and GitHub team up to take Git virtual file system to macOS, Linux | Hacker News _201711](https://news.ycombinator.com/item?id=15723926) +- git blame is not the issue that we're most concerned about. The basic, highest priority functionality in Git - things like git add - are the the issues we're most concerned about. + - git add is O(n) on the number of files in the repository. When you run `add` , git reads the index, modifies the entry (or entries) that you're changing, and writes the index back out. + - The Windows repository has about 3.5 million files. Running `git add` - when we started thinking about moving Windows into Git - took minutes. + - Git does have some functionality to support very large repositories - using shallow clones, sparse checkouts and the like. We've added narrow clones, to only download portions of the tree, and automation to handle this automatically without user intervention. + - That's the scaling work that we're doing with GVFS. And these changes bring the P80 time for git add down to 2.5 seconds. We've been contributing these changes back to git itself + +- Did I misunderstood the idea, or is GVFS essentially making git a non-distributed VCS? + - I think once you're checked out, you're still distributed as far as being able to make and push commits which modify the files you have. But obviously someone can't clone files from you which you don't yourself have. + +- ## [More on GVFS | Hacker News _201702](https://news.ycombinator.com/item?id=13594721) +- It sounds like GVFS solves the problems of big repos by only fetching and diffing files you actually need. It might handle a 300GB repo, but its does this by only working with the 1GB of the repo you actually use, and "virtualizing" the rest. If you pulled down the full 300GB repo then it would suffer from the same issues as a vanilla git repo. + - GFVS isn't really a file system like NTFS or ext3. It's a way to work with a subset of a git repo in a flexible manner (not submodules). +- Exactly. GVFS is not a filesystem based on Git. + +- I wonder how hard it would be to port the same client code to also run under FUSE on Linux/Mac. For this to take off outside of Microsoft, it needs universal client support. + - Someone at Google created an unofficial project that does something similar to GVFS. It's a bit more limited as it was focused around Android's use case, but it seems like it could be a good base? + - https://github.com/google/slothfs + +- ## [Git Virtual File System from Microsoft : r/programming _201702](https://www.reddit.com/r/programming/comments/5rtlk0/git_virtual_file_system_from_microsoft/) +- disclaimer: MS employee, not on GVFS though + - Git LFS addresses one (and the most common) reason for extremely large repos. But there exists a class of repositories that are large not because people have checked large binaries into them, but because they have 20+ years of history of multi-million LoC projects (e.g. Windows). For these guys, LFS doesn't help. GitFS does. +- a different question maybe, if you are migrating to Git, why keep all of the history? Is the ability to view history from 1997 still relevant for every day work? + +- We did try Git LFS. Actually, TFS / Team Services was one of the first Git servers to support LFS and we announced support - with GitHub - at the Git Merge conference last year. The issue with LFS is it doesn't solve all the scale problems we need to solve for Windows. +- 📌 There are 3 main scale problems with moving Windows to Git: + - Large files / content - LFS addresses this. + - Lots of files - LFS does not solve this. 1, 000, 000 small files in Git produces extremely slow status scans (10min to run git status). Breaking up a legacy code base can take years of engineering effort, so reducing to a smaller file count is not possible or practical. + - Lots of branches - LFS doesn't solve this, but GVFS doesn't either so we came up with a different solution. +- That said, listing all 3 scale issues will give everyone the full context of the problem we're solving. + - Thousands of engineers work on Windows and each of them will have 10+ branches. We're estimating 100k branches for the repo. + - To quickly perform the haves / wants negotiation that happens with a fetch / push, we needed a solution. We call it "limited refs" and I'll give more details if people are interested. +- When moving to a monorepo, Twitter had status scan troubles and solved it by forking the official Git client and using Watchman to avoid rescanning on every invocation. Obviously this is a very different approach than that of GVFS, which alters official client behavior by sitting one layer below it, so how does GVFS go about doing it? + - As a big user of JGit, Google encountered a similar inefficiency in packfile negotiation and thus created bitmap indexes. This auxiliary data structure still runs on the assumption that the client wants to fully store every object in the repo on disk, which once again is fundamentally different than GVFS's goal. I'm very curious to see how limited refs work! +- We don't want a private fork of git. GVFS is a driver that sits below git and takes advantage of the changes we're making to core git + +- Multiple repositories creates all manner of other problems. Note that google has one repo for the entire company. + - To clarify, while their super repo is a thing, but they also have hundreds of smaller, single-project repos as well. +- There are a lot of reasons to go with a mono-repo, google does the same. + +- Wouldn't it have been easier to change git than to write a filesystem filter driver? + - It's certainly something we considered and to be honest, we're actually doing both. There are two parts to GVFS, the virtualization of the objects directory and the virtualization of the working directory to manage your sparse checkout. We believe the first part belongs in git and we just recently suggested that on the git mailing list. We'll be working to build it into git as long as the maintainers agree with that direction. + - The second part of the virtualization is less clear. I don't think it belongs in git, at least right now. We needed the filter driver to pull off that piece. Once we had it, it was trivial to slide it under the objects folder as well. +- Our goal with all git/git changes isn't to change Git into something different. We want to enable better performance with large repos, even if those repos don't use GFVS. + +- ## 🚀 [Announcing GVFS: Git Virtual File System | Hacker News _201702](https://news.ycombinator.com/item?id=13559662) + - https://github.com/microsoft/VFSForGit /MIT/202412/csharp/maintenance + - [Announcing GVFS (Git Virtual File System) - Azure DevOps Blog _201702](https://devblogs.microsoft.com/devops/announcing-gvfs-git-virtual-file-system/) + - VFS for Git virtualizes the file system beneath your Git repository so that Git and all tools see what appears to be a regular working directory, but VFS for Git only downloads objects as they are needed. + - > Notice: With the release of VFS for Git 2.32, VFS for Git is in maintenance mode. + - > Note: for new deployments, we strongly recommend you consider Scalar instead of VFS for Git. +- A lot of questions like why not use multiple repos, why not git-lfs, why not git subtree, etc. are answered + +- > One of the core differences between Windows and Linux is process creation. It's slower - relatively - on Windows. Since Git is largely implemented as many Bash scripts that run as separate processes, the performance is slower on Windows. We’re working with the git community to move more of these scripts to native cross-platform components written in C, like we did with interactive rebase. This will make Git faster for all systems, including a big boost to performance on Windows. + +- For the problem of large files I think Git LFS has largely won out over git annex, mostly because it's natively supported by GitHub and GitLab and requires no workflow changes to use. + - Atlassian's Bitbucket and Microsoft's Visual Studio Team Services both also support Git LFS. + +- Pros of git-annex: + - it is conceptually very simple: use symlinks instead of ad-hoc pointer files, virtual files system, etc. to represent symbolic pointer that point to the actual blob file; + - you can add support for any backend storage you want. As long as it support basic CRUD operations, git-annex can have it as a remote; + - you can quickly clone a huge repo by just cloning the metadata of the repo (--no-content in git-annex) and just download the necessary files on-demand; + - And many other things that no other attempt even consider having, like client-side encryption, location tracking, etc. +- Git Annex is only a partial solution, since it only solves issues with binary blobs. It doesn't solve problems with large repos. + +- That still only solves half the problem with large binary blobs. The other half is that almost all of the binary formats can't be merged and so you need a mechanism to lock them to prevent people from wiping out other people's changes. Unfortunately that runs pretty much counter the idea of DCVS. + +- When git-annex finds a conflict it can't solve, it gives back to you the two versions of the same file with the SHA of the original versions suffixed. This way you can look at both and resolve the conflict. + +- +- +- diff --git a/lib-utils-git-community-usage.md b/lib-utils-git-community-usage.md index 7416bc2e..44202598 100644 --- a/lib-utils-git-community-usage.md +++ b/lib-utils-git-community-usage.md @@ -81,23 +81,6 @@ modified: 2024-05-27T09:12:06.925Z - [Creating a permanent link to a code snippet - GitHub Docs](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-a-permanent-link-to-a-code-snippet) - You can create a permanent link to a specific line or range of lines of code in a specific version of a file or pull request. -# disccuss-git-not-yet 🐛 -- ## - -- ## [Git Status Takes a Long Time to Complete - Stack Overflow](https://stackoverflow.com/questions/1183769/git-status-takes-a-long-time-to-complete) -- For me, the slowness was due to having a lot of untracked files (temporary and output files from scripts.) Running `git status -uno` , which excludes the untracked files, ran much faster, and meets my requirements - -- ## [Ways to improve git status performance - Stack Overflow](https://stackoverflow.com/questions/4994772/ways-to-improve-git-status-performance) -- To be more precise, git depends on the efficiency of the lstat(2) system call, so tweaking your client’s “attribute cache timeout” might do the trick. - - The manual for git-update-index — essentially a manual mode for git-status — describes what you can do to alleviate this, by using the --assume-unchanged flag to suppress its normal behavior and manually update the paths that you have changed. You might even program your editor to unset this flag every time you save a file. -- 👣 The alternative, as you suggest, is to reduce the size of your checkout (the size of the packfiles doesn’t really come into play here). The options are a sparse checkout, submodules, or Google’s repo tool. - -- git config --global core.preloadIndex true - - This is now enabled by default already. - -- -- - # disccuss-git-ui - ## diff --git a/lib-utils-git-community.md b/lib-utils-git-community.md index f67e369f..baeb50ee 100644 --- a/lib-utils-git-community.md +++ b/lib-utils-git-community.md @@ -345,80 +345,7 @@ modified: 2023-08-29T10:13:31.070Z - - -# discuss-git-fs -- ## - -- ## - -- ## [Gitfs: Version Controlled File System | Hacker News _202108](https://news.ycombinator.com/item?id=28263356) -- To be clear on what this is, it allows you to mount a git repo and use writes to the filesystem to autocommit and push to the remote, effectively using git and a server to synchronize directories between remote hosts. - - That is not the same thing I would think of as a version-controlled filesystem. That would be something more like the ClearCase MultiVersion Filesystem, which allows you to define versioned views of an entire filesystem. - -- I expected it to be closer to Microsoft's GVFS - - There, they used a filesystem interface to speed up checkouts for large repositories. -- VFS for Git was superceded by https://github.com/microsoft/scalar and then many of the features were merged into mainline git, so what is left now is a thin shell around git features in the form of MS's forked git binary -- VFS for Git solves the issue of having gigantic bloated monorepos used by thousands of devs, making sure user efficiently downloads only what is needed for him. - -- NixOS can also move between system generations seamlessly. The approach is entirely different though, the system is fully defined by its config files and will be recreated from scratch each time it is changed (except /home and /var, mostly). - -- It's different from git-annex in that it's using git itself (git-annex just uses git to track metadata/hash to facilitate large files), but there's a similarity to git-annex's 'Git-annex Assistant' in how it "any subsequent changes made to the files will be automatically committed to the remote". -# discuss-git-db -- ## - -- ## - -- ## 🔥 [Git as a NoSql Database (2016) | Hacker News_202104](https://news.ycombinator.com/item?id=26703808) -- In almost every database-backed application I've ever built someone, at some point, inevitable asks for the ability to see what changes were made when and by whom. My current preferred strategy for dealing with this (at least for any table smaller than a few GBs) is to dump the entire table contents to a git repository on a schedule. - -- I store all my dates in sql as text in iso format so I can easily sort them - - Strong SQLite vibes... (SQLite doesn't have a date format, it has builtin functions that accept ISO format text or unix timestamps) -- Why is this bad? - - Sql databases usually come with their own date types that are implemented with integers behind the curtains. They take up less space and are easier to sort than text fields. - -- Why not have a history table and use SQL triggers to insert the new data as JSON everytime someone changes something? - - Indeed. I have on multiple occasions written scripts to automatically generate the triggers and audit tables - -- Git annex is pretty flexible, more of a framework for storing large files in git than a basic sync utility. ("Large" meaning larger than you'd want to directly commit to git.) If you're running Git Annex Assistant, it does pretty much work as basic file sync of a directory. But you can also use it with normal git commits, like you would Git LFS. Or as a file repository as chubot suggested. The flexibility makes it a little difficult to get started. - -- Isn't the problem attempting to be solved here solved by event sourcing? Which lets you 're-create' your changes and is - ultimately- suppose to allow you effectively log each change in such a way its re-playable backwards and forwards - - Kind of, but there’s more to it. “Event sourcing” is the pattern being implemented by git’s immutable object database, but there’s also all the hashing and reference management. - -- -- -- -- -- -- - -- ## 🌵🔥 [GitDB, a distributed embeddable database on top of Git | Hacker News_202207](https://news.ycombinator.com/item?id=31987240) -- version control in general turns out to be highly applicable in many areas far beyond source code. I think it's still under-utilized. - - Yes, it's extremely common to see applications which need a datastore to end up needing lots of version control type features later on, which end up implemented ad-hoc over a general database. -- Git is an abstraction over file trees (or even more generally just chunks of data), and it turns out a ton of problems in software are easily modeled and dealt with as files in a tree. - - Lots of problems in software are easily modeled as ordered lists, but that doesn't mean linked lists are the right tool for accomplishing that. - -- GitDB doesn't handle merge conflicts, so I'm not convinced it would handle multiple clients well. The It's again marked as something they might do in the future someday. I suspect this is pretty fragile. (Note: I was _not_ claiming litestream would do such a thing. Just replication.) -- You can already store and sync issues in git repo metadata, check out git-bug: https://github.com/MichaelMure/git-bug - -- How does merging work? Would it even be acceptable to allow automatic merging in all types of application? - - To be honest, I would be completely fine with a use case that offloads conflict prevention to the application. - -- ## [How to implement git-like "branching" on a MongoDB database in Node.js - Stack Overflow](https://stackoverflow.com/questions/64635567/how-to-implement-git-like-branching-on-a-mongodb-database-in-node-js) -- I think you are diving into the world of temporal data so it would probably help a lot to start drawing timelines. - -- ## [Does git use databases? - Quora](https://www.quora.com/Does-git-use-databases) -- Git stores everything inside objects found inside .git directory. -- All the references (40 characters hash) pointing to those references are stored inside refs directory. -- git treats files and directories in 3 stages: your normal files/directories, staging area, committed area(repo). - -- ## [Is there a better database than Git (with serializable, immutable, versioned trees)? - Stack Overflow](https://stackoverflow.com/questions/7152276/is-there-a-better-database-than-git-with-serializable-immutable-versioned-tre) -- Datomic provides a persistent data storage and a built-in time notion. - -- Although the index/working copy parts of git can be separated out easily enough, git is not designed for merges or commits at the rate of thousands per second on a single machine. The core code is not even threadsafe, for the most part. You will likely need to create some new system for your data (you can still use git for the code, of course, and can also look into generating git commits to represent your data when necessary, etc). -- So libgit2 isn't thread-safe? It would seem that Git would be inherently thread-safe considering it's data structure - - Nope! It has cache structures, etc, that are not thread-safe. The core git code was only designed to run in a single-threaded manner as command line tools, after all. - -- [Git: the NoSQL Database - Speaker Deck](https://speakerdeck.com/bkeepers/git-the-nosql-database) # discuss-git-versioning/vcs - ## @@ -590,279 +517,3 @@ modified: 2023-08-29T10:13:31.070Z - 像你这种场景, 要么使用传统中心式版本控制系统, 比如 SVN, 要么通过在线的协作环境, 比如 Microsoft 自己的 Office Web 版, 或者 Google Doc. - 但回到最初的问题: 你需要的真的是一个"版本控制系统"吗? 也许仅仅是一个集中分享的地方, 也许仅仅是希望一个人修改的时候, 另一个人不能修改, 而已. - 其实!你们忽略了一件事情!pptx文件实际上是个zip文件,解压开来全是文本的xml和你加进去的视频、图片,是可以用git管理的! - -# discuss-gitlab-gogs-gitea-platform -- ## - -- ## - -- ## [Any GitHub/GitLab alternatives built for non-technical users? : r/git _202101](https://www.reddit.com/r/git/comments/l2ae04/any_githubgitlab_alternatives_built_for/) -- The difficulty, IMO, is that Git works best with plain-text files. But many non-IT (NIT) people are wedded to proprietary file formats like MS-Word. So, merely making Git more intuitive ain't going to help—NITs still won't be able to take advantage of Git. - -- Wikis can provide good collaboration and version control for text, though, and most people should have at least a passing familiarity with the concept by now. - -- I Agree. The answer is something like Confluence. - -- What is your goal / what should this software mainly be used for? (What problem are you trying to solve?) - - If you just need versioning, there are many simple backup or synching programs. - - If you need "forking", there are online collaboration office tools which might be a better fit. - -- Gitea is a lot simpler than GitLab/GitHub and still has the core functionalities. - -- Check out gitbook. - -- ## [Harness launches Gitness, an open-source GitHub competitor | Hacker News _202309](https://news.ycombinator.com/item?id=37598082) -- Codeberg (2019), which was based on Gitea until they forked it into Forgejo (2022). - - Codeberg is a service not a separate software. Just like you wouldn't count salsa.debian.org or framagit.org as separate from GitLab, they are the same with maybe some local customization. - -- How does Gitness differ from already existing open source alternatives, such as Gitlab, Gitea, Gogs, Forgejo, Codeberg, Gitweb? - - Gitness actually launched in 2012 under the name Drone, with a focus on continuous integration. - - So Gitness has a very strong, mature pipeline engine that is also very popular in the Gogs and Gitea community (Gitness is backward compatible with any Drone yaml). - - Of course, this is just our initial launch which is a very important milestone, but we have a lot of feature gaps and a lot of work to do to make our Code Hosting solution a more interesting replacement. Stay tuned. - -- I won't trust Harness with anything open source. It's the same company that killed the open source Drone CI after acquiring it. They changed the license such that you could contribute to it but could not use it if your revenue was more than 1 million USD. They didn't fix bugs that were well known to them because they were working on the enterprise version of it. - -- How does this compare to e.g. Forgejo, Gitea, Gogs, self-hosted GitLab, or other alternatives? - - Forgejo in particular has self-hosted actions runners that can be registered offline, and the runners themselves can be given labels and execute most existing GitHub actions (in fact, the yaml format they use is intentionally meant to be compatible with GitHub actions). - - While the Pipelines UI looks nice, it hides all the very real details of deployment (and configuration) in a variety of environments. This is one thing Forgejo does well compared to e.g. Gitea for CI/CD, thanks to being very flexible in configuring runner secrets, registering runners, and so on. - - The reason I am emphasizing CI/CD is because hosting code and a bug tracker is only one small aspect of GitHub IMO. The real big things are its popularity and GitHub Actions. It's not enough for many people (and businesses) to simply host code anymore. Many now expect commits pushed to certain branches to execute a variety of workflows -- from unit tests to full-on Kubernetes deployments. - -- They should host a demo instance like Gitea does. - -- Interestingly it looks like this is partly a fork of Gitea (or at least, incorporates large amounts of code from Gitea) - - It is largely based on the existing Drone repository, but for Git capabilities we used the Gitea fork of https://github.com/gogs/git-module - -- looks more complicated than forgeo/gitea . gitea already servers all github needs for us - -- ## [Four years of SourceHut (SourceHut is a open source github alternative) : r/linux _202211](https://www.reddit.com/r/linux/comments/ywbrtc/four_years_of_sourcehut_sourcehut_is_a_open/) -- if only sourcehut was in any way user friendly. making pull requests and looking for issues is such a pain - - It's email-based, not PR-based. Although devs use git-request-pull instead of git-send-email. - - Also, issues go to the https://todo.sr.ht page. It's just that some devs don't use that. - -- ## [Gitlab like server in nodejs _201702](https://github.com/open-source-ideas/ideas/issues/29) -- I created a basic ssh server that can now clone and push changes. Still needs work on public key auth. Currently using password authentication. - -- I feel like Gitea already fills this niche. GitLab supports many features. It's arguable the most complete of the OSS Git front end web apps. Gitea lacks many of its features, but it's considered extremely lightweight, enough so to run well on a Raspberry Pi. - -- We need a decentralized open-source alternative, not Gitea or Gogs. - -- ## [Does anyone know of a Node.js alternative to GitLab? : r/node _201309](https://www.reddit.com/r/node/comments/1n9byh/does_anyone_know_of_a_nodejs_alternative_to_gitlab/) -- I'm pretty sure nothing like that exists. -- Well Github was originally written on top of a library called Grit which allowed for Ruby to interact with repos. Theyce since moved on to use a C library called libgit. It's possible to write a Node plugin that will interact with libgit, of one doesnt already exist. This would be my first move if I were in your shoes. Once you have a javascript implementation of something like Grit, you'll be able to manipulate and pull information from repos. - -- ## [OneDev - Selfhosted open source alternative to GitHub/GitLab : r/selfhosted _202108](https://www.reddit.com/r/selfhosted/comments/p1fikz/selfhosted_open_source_alternative_to_githubgitlab/) -- Gitea is certainly a really nice project. - - We even used its predecessor gogs for some time, before switching to OneDev. - - The main reason is lacking of functionality such as pull request approval, reviewer auto-assignment based on contribution history, easy symbol navigation while reviewing pull request, selecting any diff/code to start discussion, real-time preview when authoring markdown, customizable issue field and state etc. - -- Gogs/Gitea is perfect for personal usage. But for teams with dozens/hundreds of people, some solid features need to exist to be efficient. This is what we built into OneDev. - -- ## [Re: [jgit-dev] Introducing OneDev - an open source git server _201901](https://www.eclipse.org/lists/jgit-dev/msg03748.html) - - Looking at https://github.com/theonedev/onedev/blob/master/core/pom.xml, it appears this is a web interface that uses JGit for Git support. - -- Yes it is using JGit for most operations. JGit API is very well designed and is a joy to use. - - The performance is very good, except for long operations such as full clone. - - So for pull/push I am calling native git, but for other operations which may need to be executed several times during a request I am using JGit which is much faster thanks for the in-process cache. -# discuss-git-alternatives 🆚️ -- ## - -- ## [Darcs - Another open source version control system | Hacker News _201205](https://news.ycombinator.com/item?id=3947103) -- The primary pull of the "patch theory" is that it will allow you to share code more easily between different "patch sets" (branches / forks). - - The reality of software projects means that you can't automate such a process except in the most trivial cases, and other VCSs handle the trivial cases already. - - By contrast, Git/SVN/Hg folk think about snapshots of development. So it's a different paradigm. - -- -- -- - -- ## 要想实现 Google 代码管理方案,目前开源解决方案只有 Meta 的 Sapling ,但是对 Git 兼容不太好; -- https://x.com/genedna/status/1797927349624901967 - - 我在做一个 Git 兼容开源方案 Mega, 实现确实很复杂,但是慢慢能看到雏形,争取今年能 Release 一个版本。 -- FYI:我们正在给 Sapling 加 .git 的支持,这样用户可以既可以用 sl 命令也可以用 git 命令 - - Mega is an unofficial open source implementation of Google Piper. - -- ## [为什么很多大企业都在用收费的perforce而不是免费的svn或者git? - 知乎](https://www.zhihu.com/question/23930380) -- 主要还是SVN和GIT都对二进制文件支持很差. GITHUB还特别针对大型文件做了GIT-LFS插件用来支持这种超大文件. - - 而大型研发公司. 特别是做3D软件的. 分分钟容量爆棚 - -- 之前不觉得P4有多屌,直到在P4里面创建了有分支功能的stream库,我只能说实在太好用了,一切都是那么清晰。 - - 问了一下,初创公司,每个用户授权大概8000+ - -- 好像是从15年版本后开始的,还有个1000次提交次数的限制,需要扩展人数可以联系我 - -- ## 🌵 [Pijul is a free and open source (GPL2) distributed version control system | Hacker News _202402](https://news.ycombinator.com/item?id=39452543) -- Do you know of any FOSS alternatives that handle that stuff better (specifically binary asset handling and permissions)? - - Pijul does binary files natively, actually. Permissions aren't hard to add, if anybody had a real-world case I'd be happy to help. - -- the places where I've seen people leverage the folder-level permissions in Perforce (in the games industry) would be like: a contractor that provides art would only have access to the portions of the project that relate to the art they're working on but not the code; translators might have read access on one directory and write access on another directory. - - In academic settings I've seen Perforce used such that an instructor has read-write access on a directory and students have read-only access on the directory, and then each student has a subdirectory where they have read-write access and everyone else has read access, so that everyone can play each other's games. - - You can do stuff like this in git with submodules but it's somewhat complicated and difficult to teach to non-programmers. - - The mathematical/theoretical foundations are clear, but the target audience is unclear, so I'm not sure if these are use-cases that you consider to be within the project's scope or not; just sharing how I've seen the permissions models used in the games industry. - -- some indies use Subversion, but Perforce is the industry standard. - -- Git compatibility is a great way around this problem. I have been enjoying Jujutsu lately. -- Supporting conversion with some lossy tendencies is a good idea, but maintaining compatibility will stifle innovation as al bugs & design decisions cannot be fundamentally worked around. - - Adjacent, I heard folks praising Forgejo for its Actions & Microsoft GitHub compatibility, but that means you are still left with the same YAML spaghetti and its other limitations. What would have been nice is something better for CI--something that prompts the project to want to switch to get a better experience. - - As such, while I agree with the moral reasons to switch to non-proprietary software, the reason for switching is philosophical, not philosophical + technical. I feel being a wrapper around Git or Git compatibility will likely fall in this category rather than being more compelling. -- Not really. The real innovation of a lot of these alternative DVCS systems is that they free the state of the source from being dependent on the history that got you there. Such that applying patches A & B in that order is the same as applying B' & A' -- it results in the same tree. Git, on the other hand, hashes the actual list of changes to the state identifier, which is why rebasing results in a different git hash id. - - So long as you require git compatibility, you're kinda stuck with git's view of what history looks like. Which is rather the point. -- jj is not patch based, like pijul, but snapshots, like git. - - A sibling commentor points out the change id stored by jj: it is true that at the moment, this isn't really exportable to git in a native way. However, there is a path forward here, and it may come to pass. Until then, systems like Gerrit or Phabricator work better with jj than systems like GitHub. -- Jujutsu uses change IDs, which are an abstraction over commit IDs, that are stable over operations like rebasing. - -- So Pijul is patch-based. And not in the boring implementation-sense of storing changes as a series of patches. In the interesting sense that patches can be ordered in more arbitrary ways. - - On the other hand Git is snapshot-based. And Git was built for the Linux Kernel (specifically from the perspective of the lead maintainer). -- My understanding is that a big part of the reason that Git is snapshot based is for reliability and for ease of checkout -- being snapshot based means Git doesn't need to replay commits every time you check things out. - - That likely comes with some downsides (cherry-picking does come to mind, yes), but also seems like some serious upsides, one of the biggest one being that simplicity. It's relatively easy for me to reason about what Git is doing under the hood. - - I like that I'm seeing that Pijul's patch operations are associative, I like at first glance what I'm seeing it say about merges, but it's not making it clear to me what the downsides are. -- There's no reason you can't cache tree snapshots in a pijul/darcs setting. That's just an implementation detail. The difference is more in how a rebase or merge operation works internally, and how essential the particular history is to the current workplace state. - -- 🆚 Pijul has a number of stated strengths over Git, and looks like the version history is implemented as a CRDT from my first impression. Some of the statements make me wonder how many conflicts occur in real use. If they are equal to or less than the number it produces, great. If more than what Git produces, that's a barrier to adoption, as merge conflicts are one of the biggest pains when using Git. - - 🐛 Git compatibility is a key missing feature. Git had this with Subversion, and I think it's a big reason why Git won over many of the Subversion crowd. - -- I'm watching this (and Jujitsu, Sapling, etc.) with interest, but I wish there was more focus on Git's real weak areas. Yes it sometimes makes merge conflicts more difficult than it could, but you can generally deal with that. -- 🐛 The bigger problems are: - * Poor support for large/binary files. LFS is bare-minimum proof of concept. - * Poor support for large projects. Big monorepo support is definitely getting better thanks to Microsoft. Submodules are a disaster though. - - The basic premise of Pijul is that the way they model changes leads to better merges, fewer conflicts, and (crucially) no cases of bad merges. Git can complete merges and do it incorrectly -- Large/binary files: Pijul splits patches into operations + contents. You can download a patch saying "I added 1Tb there" without downloading any single byte of the 1Tb. No need to add any extra feature. - - Large projects: Pijul solves that easily using commutativity, you can work on partial repos natively, and your changes will commute with changes on other parts of the monorepo. - -- Just like how Sapling is compatible with GitHub, I'd love to see Pijul being compatible with GitHub wrt creating at least a read-only mirror. -- Is sapling compatible? It gets rid of your .git directory. - - It's network compatible in that you can clone, pull, push, etc with a github repo. - -- All version control tools have the same problem since AFAIK none of them care about the semantics of the program being version-controlled (except Unison). - -- 🆚️ IIUC, Pijul has all the good parts of Darcs, with the exponential merge issue resolved. - -- Does Pijul handle branches better than Darcs? I _love_ using Darcs but I had to stop because there was no good way for my teammates to see my new branches (really separate repos) unless I told them myself. - - pijul fork. There you go, I wrote an entire key-value store just to get that to work. It turned out to be faster than all others, but that wasn't intentional. -# discuss-fossil -- ## - -- ## - -- ## 🔁⚖️ [The Fossil Sync Protocol | Hacker News _202402](https://news.ycombinator.com/item?id=39464938) -- The problem with single file formats is they don't play nicely with file sync tools in what I'd call "common" scenarios. - - Due to the way it's laid out, a git bare repository will work quite well with a per-file syncing system because references are stored as files pointing at the hashed object store. - - So the worst you can do even without central coordination is have a reference conflict. I'm sure bad things can happen, but for the purposes of "keeping repos synced via syncthing" it works well enough (note: this is different to trying to keep a working repository synced, which I wouldn't recommend). - -- Since it uses SQLite under the hood, Fossil as a version control system might be able to scale much more gracefully than git for huge monorepos. I think about this often but haven't found a way to effectively use this knowledge yet, since I haven't worked in a giant monorepo shop yet, nor have I found any third parties talking about their experience with this. -- 🐛 They tried using Fossil for netbsd (and may still use it for some things, I'm not sure). Fossil was not designed for large repositories - - [Fossil Forum: Fossil and large repos? _20200908](https://fossil-scm.org/forum/forumpost/5ad122663cbae98f) - - It could be optimized for that case, but since there doesn't seem to be a lot of interest, I don't know that anyone is going to do the work. - -- Microsoft uses git for Windows repository pretty successfully. It started with custom VFS implementation and fork of git but by now everthing is upstreamed and VFS is not used anymore. - - Git original implementation did not scale to huge sizes. Needed specific development work to change assumptions. Presumably similar design improvements could change fossil. - -- I love the concept of Fossil being in SQLite, but there's a reason that Mercurial invented revlogs and Git tries to keep related objects close to each other in packfiles. Sometimes, you really do need a dedicated file format optimized for specific use cases. I'm completely unsurprised OpenBSD wasn't able to pull this off. - -- For a large monorepo network filesystem approach is inevitable. Every local storage approach has limits and breaks down eventually. - -- > The "bag of artifacts" data model used by Fossil is apparently an implementation of a particular Conflict-Free Replicated Datatype (CRDT) called a "G-Set" or "Grow-only Set". - - Isn’t this just by virtue of content addressing objects? In that sense Git’s odb is also a G-set. -- If you look at the definition of CRDTS, it seems trivial that all distributed scms must satisfy CRDT properties. Some observations are trivial once you think about it, but worth saying to connect to different audiences with different interests or backgrounds. I wouldn't be surprised if they added this because they got the question many times. The rest of the paragraph makes clear that they did not develop fossil in the context of CRDTs, and nothing in the rest of the document depends on this observation. - -- 🤔 Is this, or could this be modified to be, able to sync an sqlite database (or really the data it contains) between devices? I'm aware of other ways to do this but if there was an internal sqlite way to do this... - - No, this protocol doesn't deal with SQLite. In fact, SQLite in Fossil is just an implementation detail, the design doesn't depend on it. - -- ## [Fossil | Hacker News_202203](https://news.ycombinator.com/item?id=30815693) -- Git's 'killer-feature' by now is simply its ubiquity - - for Fossil's this could be claimed as a single binary that does it all. - - Just download the binary, and you've got the ubiquitous set of project-related facilities: VCS/tickets/docs/wiki/team/forum/chat with simple aporoach to sync and self-host. - -- It sounds to me that people are split on whether or not SCM should include things like issues and wikis directly, or let others solve it. - - Considering this is the largest point between fossil and git that I can see, maybe we should just make it so git has the capability to expose an extension API for plugging additional capabilities like this in. - - Then we could probably all use git and just be happy. You could theoretically use fossil's issues and wikis with git. - -- It's pretty much Gitea in a single SQLite file (Wiki, tickets, version control, etc.). It's weird, but you can edit all of these things off-line and then sync everything back. fossil ui hosting the server for my docs locally, and from my home server is super useful and easy. - -- Issues and pull requests don't get replicated by git. If github goes down, you can't interact with issues. If github ever turns evil, or you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations. - - Git is a distributed, replicated data format. Why are issues fully centralized? Its bizarre - - Fossil is far from perfect, but I think putting the issues and stuff into the repository itself is brilliant. -- It is brilliant to integrate things with the decentralized source control itself -- But despite its brilliance it's not always the right approach. - - It's very easy and reasonable to want more than what is realistic for something deeply integrated with the source code itself to provide, if only for inherent conflicts of desire, let alone any question of manpower. - - There are very good reasons to have entirely separate (and even multiple-of-kind partially overlapping/integrating/cross-referencing) systems for source code management, issue tracking, code review, forums, IM communication, wikis, public websites, docs (of whatever kinds and types for various audiences and authors, or public or not, or team-level spikes or plannings or retrospectives)... - - One aspect of Fossil I found weak was its user capabilities (no custom user categories alone is a deal breaker for so many things) but flaws in the execution of a fully integrated thing isn't really my point, my point here again is just that full integration despite its overlooked benefits and brilliance when applied to certain things is still not necessarily the right choice for something. - -- My favourite thing about fossil is that the repo is a single SQLite database file so it’s extremely to just back it up or keep the repo in cloud storage. With Git I’ve always had problems with conflicts in the .git directory which messes things up, but fossil is a single file so it backs up to the cloud wonderfully. - -- I'm curious how others do **code review** in fossil? It's something that GitHub is quite good at in my opinion; raising pull requests, having pre-merge checks, commenting on individual lines of changes, etc etc is all useful. It's something I can't see how to do in fossil. - -- I am not sold on the wiki and issue tracker. What would be a killer feature is a web UI interface to fossil commands like sublime merge for git. - -- One thing that has prevented me from trying out fossil is there is no squash. The team has a principled stand on not having it. -- The author of Fossil considers rebase harmful, and because of that, it wasn't implemented - - Fossil has private branches which can serve the same purpose. When you merge a private branch it looks just a single commit, similar to a squashed merge. - -- ## [Fossil | Hacker News_202009](https://news.ycombinator.com/item?id=24643200) -- having issue tracking in the repo prevents lock-in of that data - in the way that the github platform works, for example. - -- I use fossil mostly as a Customer/Project KB/Documentation tool, when a new project starts i have all the documentation, code snippets/examples in one single file, when the project is finished, i have to give one sqlite.db file over to the customer and that's it. LOVE IT, a really great tool! - -- Would like to see a SCM that: - - handles large files effectively (build artifacts, 10-40GiBs each, and other binary dependencies) - - partial checkout of the repo/view - - git style operations (have stage area, can stage parts of a file, can stash changes and reapply later, cherry pick) - - can view the history of an individual file (support file relocation) - - access control on individual files, and partial review of the repository (views are "granted" to developers) - - good tooling - - immutable when it makes sense (e.g. you cannot changed a published commit) - - works offline (if possible) - - large mono repo -- I evaluated git annex and git lfs, and finally chosen Perforce, mainly for its large file handling, view for each developer and ACL, but the lack of flexibility makes me don't want to commit, and every time I do a merge, I say to myself, "uuh, this again". The other thing it lacks is the "ease of mind", with git, everything is checksummed, if the content changes, it will be noticed by git, with Perforce, you have to tell it you want to edit it. - -- There are several bug tracking systems that store their data inside the repository (and as a result, branch / merge / push / pull automatically) -- including the venerable "vi bugs.txt" system which works surprisingly well from experience. - - What fossil brings that those systems don't is indeed the network effect as you pointed out. It's integrated with the web frontend, and is thus used by everyone using fossil and fossil's bug tracking, based on experience with cvstrac, is low ceremony, easy to use and reasonably effective -- even more than "vi bugs.txt" which sets a remarkably low ceremony bar. - -- ## [Fossil – Simple, high-reliability, distributed software configuration management | Hacker News_201412](https://news.ycombinator.com/item?id=8697028) - -- Fossil is version control software with "embedded" wiki and issue tracker, while Trac is a wiki and issue tracker which can, optionally, interface with one or more external vcs systems. - - Fossil stores the wiki and issue data in the repository itself (SQLite), while Trac stores it in an external database (PostgreSQL, MySQL etc.. SQLite would probably work too!). - -- ## [Show HN: Grit – a multitree-based personal task manager | Hacker News_202104](https://news.ycombinator.com/item?id=26673221) -- What's the difference between a dag and a multitree? - - prevents diamond shapes - - An earlier version of the program actually used DAGs, but I found it a little underconstrained. I got pretty excited when I discovered multitrees, as it seemed to be exactly what I needed the whole time. -- Precisely; a multi-tree has a unique path between two nodes. - - On the same note, I wonder what is the relation between dags/multitrees and semilattices. They seem to be very similar concepts afaict. - -- 🤔 How is the data stored? Would it be difficult to sync among different machines? - - Just SQLite - two tables, one for the nodes, one for edges + some fancy constraints and queries. - - As for the syncing, that would be really nice, but I haven't come up with an elegant way to do it yet. Suggestions welcome, if anyone has ideas! -- git. The right storage backend is either git, or a git-like Merkle tree. This is small data. Individual files for objects are fine. Compacting is better, but not critical. - - sqlite is the wrong tool for the job, beyond an initial prototype. git and hg figured this stuff out decades ago. -- Fossil would disagree that SQLite is somehow wrong for this use-case. - - Fossil does seems to have issues when the VCS grows into many many gigabytes of data, like the entire OpenBSD source tree didn't work out very well in Fossil, but the chances of a personal task manager ever growing that size is slim to none I would imagine. - -- I use a flat text file with exactly this structure, just indenting when I need a new layer. - - this supports a slightly more interesting structure than an indented text file: it's actually a DAG where large subgraphs are trees. This allows links between different nodes. That's not possible in an indented text file. - -- TiddlyWiki uses a similar data model for table of contents by default and I love it! I think the multitree constraint is a good idea over a general DAG. - -- ## [Why I'm using Fossil SCM instead of other source control systems (2016) | Hacker News_202206](https://news.ycombinator.com/item?id=31634560) -- I’m just waiting for the next VCS that brings significant changes. We’d absolutely switch over if there was some feature we wouldn’t get elsewhere. But it’d need a couple of months/years of sustained advocacy. - - The next big thing will be semantic code versioning. I.e. a tool that **understands language syntax and can track when a symbol is changed**. - - There are already experiments in this area, but I don't think any are ready for mass adoption yet. - - The fact that it's 2022 and we're still working with red/green line-based diffs is absurd. Our tools should be smarter and we shouldn't have to handhold them as much as we do with Git. It wouldn't surprise me if the next big VCS used ML to track code changes and resolve conflicts. I personally can't wait. - -- Feature for feature Fossil is more like a competitor to Github or gitlab. - - Basically it is a SCM based on sqlite that is a lightweight version of those websites offer. - - To add some detail here. The features it offers (tickets, wiki, chat, forums, etc) are stored within the repo, unlike github or gitlab where those things may be separate. - - Basically, if you have the repo and the fossil binary you have everything. Is this better? I never saw a lot of advantages in my style of work, but i could see this being huge for someone who has intermittent connectivity. Or maybe someone who wants to use the ticket tracking, etc without setting up a separate server or public instance. - - I just love that fossil exists and there is a diversity of opinion on how things can work. - -- Fossil came out in a time when your options were basically CVS, SVN, or something commercial like Perforce. - - Git is an innovation that came out around 2005 (A year before Fossil), and it took a few years to get some traction, but holy moly are either of these better than what came before. - -- I suppose a competitor could also have some kind of git compatibility shim built in to ease the adoption. - - Fossil does let you import and export git I think. Fossil just has the wiki and issues on its side - -- I hear a lot of larger teams insist on squash commits for PRs. Fossil isn't a fan of squashing. - -- Would the wiki part of fossil be a good static site generator? - - Not in the general case, no. Fossil-generated wiki/markdown output expect to be browsed within the context of a fossil repository, and will generate links accordingly. - - There might be very limited use cases where it would work reasonably well, but not generically. e.g. adding a link to a local file or another wiki page will not work if the output is browsed from outside of a fossil repo instance. diff --git a/lib-utils-git-dev.md b/lib-utils-git-dev.md index ec95e125..6fbdf766 100644 --- a/lib-utils-git-dev.md +++ b/lib-utils-git-dev.md @@ -15,6 +15,7 @@ modified: 2023-08-29T10:11:26.348Z - revision history - 使用ssh数据传输的方案有官方支持 - 传输大文件的方案LFS有官方支持 + - 传输海量文件的方案,可参考gvfs/scalar - cons - 体积会越来越大 diff --git a/lib-utils-storage-filesystem-web-community.md b/lib-utils-storage-filesystem-web-community.md index efa87ef7..523b5a9f 100644 --- a/lib-utils-storage-filesystem-web-community.md +++ b/lib-utils-storage-filesystem-web-community.md @@ -49,6 +49,34 @@ modified: 2023-09-16T17:43:09.215Z - I was expecting this to be a way to mount so-called SQL Archives (https://sqlite.org/sqlar.html) but this is just as cool. - I'm also working on something like this: https://github.com/Airsequel/SQLiteDAV My mapping is: table -> dir, row -> dir, cell -> file +# discuss-sshfs +- ## + +- ## + +- ## [A currently maintained fork of SSHFS | Hacker News _202309](https://news.ycombinator.com/item?id=37390184) +- If you want something in user land and you don't mind emacs there is TRAMP “Transparent Remote (file) Access, Multiple Protocol”. + - My favorite thing about using TRAMP is being able to cd to a directory on a remote system, and then cp a file either from my working directory to my local machine (or another remote!), or from my local machine to the current working directory. + - Before I started using TRAMP, my flow for this was: SSH to a remote system, locate where I want to copy a file to with cd + ls, kill my SSH session, and then scp or rsync the file over, and then usually SSH back into the system. + +- Couldn't you just use sftp? + - Idk when you stopped using scp, but scp has been deprecated, and at least w/openssh, using sftp under the hood for years now. You probably have used it if you've scp'd since 2020. +- My point above was that I was making and killing multiple SSH connections to find where I want to copy a file, and then do the copy. Using SCP with an SFTP backend would still do that. + +- I think SFTP is a good but underrated protocol, when mirroring a file tree bidirectionally makes more sense than cloning one to another. + - SFTP is a major step up from FTP, but there's a lot of unrealized potential on the server side, so you can't just work on better clients. Both OpenSSH and the GNU lsh server only offer an old version of the protocol -- v2 + +- rclone mount is my go-to now for sshfs functionality - better performance, stability and caching options + - rclone cannot write to the middle of a file though, without transferring the whole file. That is my main issue with it. Maybe sshfs has the same limitation though. +- rclone mount uses sftp in the background which compresses the entire stream (you can control that by passing args to the ssh command spawned by rclone) but it doesn't do it per-file. In practice I don't know if there is a difference. + +- Nautilus (Ubuntu's file explorer) allows to mount SFTP folders. Supposedly it uses `gvfs` under the hood. + - Note that SFTP uses an SSH connection for its file transfers, so I have not seen an UI difference from SSHFS + +- gvfs has a bridge to fuse, cf. https://manpages.ubuntu.com/manpages/trusty/man1/gvfsd-fuse.... -- that means: Yes, you can use gvfs mounts natively in all other non-GNOME/GTK-applications running on your computer. + +- Is there a more security-oriented alternative to SSHFS, where the connecting client won't be given shell access on the server? + - If the user account is only supposed to have file transfer capabilities/no shell access, add it a to a specific group e.g. `sftponly`, and only allow this group to use the `internal-sftp` command in `/etc/ssh/sshd_config` # discuss - ## diff --git a/pm-noter-notable.md b/pm-noter-notable.md index e287bafc..83e7898b 100644 --- a/pm-noter-notable.md +++ b/pm-noter-notable.md @@ -34,6 +34,7 @@ modified: 2023-11-28T14:48:45.910Z - ⌛️ version history - diff - replay: 可调倍速,回放时的表现可以和操作时不同,在回放模式下显示diff-view更直观清晰 + - 基于代码的回放能解决视频难以实时更新的问题, video-but-auto-update - 🔍 search: rag, code-search, ai-chat - 针对代码优化的搜索可作为技术卖点和产品卖点,可参考github-code-search/algolia - 文档和代码同步更新、搜索 diff --git a/thread-blog-work-career-xp.md b/thread-blog-work-career-xp.md index b77c4a29..947e42d8 100644 --- a/thread-blog-work-career-xp.md +++ b/thread-blog-work-career-xp.md @@ -14,7 +14,30 @@ modified: 2022-11-08T10:34:34.820Z - ## -- ## +- ## [大龄被裁大头兵职业感想 - V2EX _202501](https://www.v2ex.com/t/1101570) + - 过去的 10 多年,回顾起来觉得平常,却是 IT 的黄金时代, 我个人历经 空中网 - 阿里巴巴 - 创业(失败)- 乐鑫 - * - 某中厂(被裁) + - 在那个急需技术人员的时代,我几乎没主动找过工作(各种机缘巧合认识,然后聊一下就过来),薪资也是一步步涨 + - 简单说,大部分人都是跟着公司发展的(离开了大厂属性,也就俨然众人),除非真的能力超群 + - 这就是目前所在公司业务开发的现状,一个项目下来,X 人日,Y 天联调,Z 天测试,上线,继续下一个项目 + - 不需要考虑代码质量,不需要考虑长久维护,不管大的小的项目,从上往下一推,再砍几天人日,上线代表结束,下个烂摊子给谁就是谁 + - 作为程序员,我们知道人有差异,但这种机制,就是去掉这种差异性 + - old man 引以为豪的一些技术,慢慢被颠覆,如同我入行的 JSP 、Java RMI + - 与此同时,新的技术,又是旭日东升,如同现在的 AI +- 经验与教训: + 1. 单纯技术体系而言:大厂/独角兽,能进就进,尽量待久一点,无非打鬼升级,找准位置,不要幻想外面就能成长更快,技术最终需要业务推动;如果不长期走技术路线,可以考虑小而美 + 2. 选长期业务,不做短平快业务,否则不管大厂小厂,和外包没什么区别 + 3. 技术积累一个道理,选择需要长久积累的领域,CRUD Boy 没有未来 + 4. 想一下你的可替代性,和年轻人的对比 + 5. 找到兴趣点,不要计较短期的收益 + +- 目前是有困境,及时找到下一个“快消品”工作,也会下一次裁员 + +- 感谢,,总结的很务实,长期业务才是关键还有就是可替代性,技术是一方面,业务熟悉度也是一方面,自己手里必须要有一个盾牌,技术其实在生产中,都那样,尽可能抓住业务,并有护城河才是真。另外一味跳槽追求更高薪水,虽然钱到手了,但每一家都是大头兵,扎不住也是问题。 + +- 分享的很中肯,不要去死磕技术,应该思考业务。正如氢能源也是清洁能源为什么没有市场,因为所有技术专利都给日本垄断了,这时候在继续死磕氢能源的技术路线就是错误的。更不要在技术上纠结茴字有多少种写法,还不如思考如何快速实现功能让市场进行检验。 + +- [国企上个破班筋疲力尽 - V2EX](https://www.v2ex.com/t/1101342#;) + - 你累死累活,干这自己的事,你在公司做自己想做的事,然后累死累活,打了个 C ,怪谁呢?你要干领导想干的事才能打高分啊 - ## 又在讨论大小厂,对于吾等菜鸡多年摸爬滚打的经验来说,工作好不好看运气 - https://x.com/VincentMucid/status/1868549734803341467 diff --git a/toc/toc-lib-format-office-excel-xlsx-utils.md b/toc/toc-lib-format-office-excel-xlsx-utils.md index 93fa4a1e..0f39cda9 100644 --- a/toc/toc-lib-format-office-excel-xlsx-utils.md +++ b/toc/toc-lib-format-office-excel-xlsx-utils.md @@ -186,6 +186,18 @@ modified: 2023-01-09T11:04:13.958Z - This is largely a re-write of Handsontable's https://github.com/handsontable/ruleJS, and https://github.com/sutoiku/formula.js/. - The parser was derived from Handsontable's, and many of the formulas were created with FormulaJS's formulas as a reference point. +- https://github.com/LesterLyu/fast-formula-parser /MIT/202205/js/inactive + - https://lesterlyu.github.io/#/demo/fast-formula-parser + - Parse and evaluate MS Excel formula in javascript + - A fast and reliable excel formula parser in javascript. Using LL(1) parser. + - This very excellent project is now being managed as part of SheetXL + - [A Fast Excel Formula Parser and Evaluator | Hacker News _202205](https://news.ycombinator.com/item?id=31365777) + - https://github.com/sheetxl/sheetxl /MIT/NonOpen + - https://www.sheetxl.com/ + - SheetXL is a spreadsheet and a data-grid. Fast⚡, beautiful, and compatible with Excel. + - Built using React, Typescript, and MUI + - Built from the ground up using React + - https://github.com/borgar/fx /js - Utilities for working with Excel formulas - A tokenizer, parser, and other utilities to work with Excel formula code, specifically syntax highlighting. diff --git a/toc/toc-office-suite-web.md b/toc/toc-office-suite-web.md index e54e1691..96bcd764 100644 --- a/toc/toc-office-suite-web.md +++ b/toc/toc-office-suite-web.md @@ -134,10 +134,12 @@ modified: 2023-03-09T13:47:07.317Z - Encrypted, secure, user-owned productivity suite - 依赖slate.v0.47、handsontable.v7 # office-viewer -- https://github.com/cweijan/vscode-office /MIT/202401/js +- https://github.com/cweijan/vscode-office /MIT/202412/js - 让VSCode支持预览PDF, Excel和Word等格式, 并增加markdown所见即所得编辑器 - 支持预览xlsx, docx, svg, pdf, zip等格式, 后来才增加markdown编辑器 - - 该扩展在vscode内集成Vditor + - 依赖docxjs、sheetjs、vditor(md)、pdfjs + - [Please support PPT/PPTX files _202211](https://github.com/cweijan/vscode-office/issues/166) + - I have done research on this, but due to the complexity of ppt/pptx, it is impossible to display it in js. - https://github.com/501351981/vue-office /MIT/202401/js/vue/react - https://501351981.github.io/vue-office/examples/docs/ diff --git a/wiki/lifehacks/tool-os-win-wsl.md b/wiki/lifehacks/tool-os-win-wsl.md index f1fa9175..36daf035 100644 --- a/wiki/lifehacks/tool-os-win-wsl.md +++ b/wiki/lifehacks/tool-os-win-wsl.md @@ -55,7 +55,10 @@ modified: 2020-12-22T12:41:57.687Z - ## -- ## +- ## [How to develop on Windows: comparing native, MinGW, Cygwin, WSL | Hacker News _202407](https://news.ycombinator.com/item?id=41059548) +- Windows can't handle symlinks in a sane way because they're a source of privilege escalation exploits on Windows. So git repos with symlinks in the require a security degradation to use them natively. + +- there are a few specific areas where developing on Windows is the best platform. Game development is one of them: DirectX 12 is the industry standard graphics API, and the first- and third-party tooling related to it is cream of the crop on Windows. - ## wsl 下居然可以直接运行 windows 应用? - https://twitter.com/geniusvczh/status/1756061643346415638