davvid

No, Git is alive and well. Git is under active development and continual iterative improvement.

Github might be on the decline, but git != github

davvid

3 ay öncediscuss

git-difftool is quite helpful, especially if you want an easy way to integrate existing file-based diff tools.

davvid

6 ay öncediscuss

Nor Catmull, unfortunately. FWIW, the article is centered around the financing and IPO side of the story.

davvid

7 ay öncediscuss

> We did not want to spend time maintaining a backward compatible parser or doing code archaeology. So this option was discarded.

Considering all of the effort and hoop-jumping involved in the route that was chosen, perhaps this decision might be worth revisiting.

In hindsight, maintaining a parser might be easier and more maintainable when compared to the current problems that were overcome and the future problems that will arise if/when the systemd libraries decide to change their C API interfaces.

One benefit of a freestanding parser is that it could be made into a reusable library that others can use and help maintain.

davvid

8 ay öncediscuss

The "official" repo is the gitlab repo[1], but the github mirror has more watchers/stars.

[1] http://gitlab.com/garden-rs/garden

davvid

8 ay öncediscuss

If you're into multi-repo setups then you might be interested in garden. I built this specifically for handling dozens of repos as single units.

https://github.com/garden-rs/garden

davvid

9 ay öncediscuss

    > I had to get my project to emit compile_commands.json,
    > get clangd, figure out which things about our build
    > process clangd was not understanding from 
    > compile_commands.json and add them in .clangd

That sounds rough. This is anecdotal, but in my Linux corner of the world, ccls has been an easier user experience as a C and C++ LSP since I've never had to resort to messing with flags in the generated file.

I haven't used clangd myself, though, so I can't say either way, I just know ccls works well.

By convention I tend to have the generated build system in build/ at the top-level of the repo so that the file is at build/compile_commands.json. That, or I'll arrange to have a symlink there pointing to one generated elsewhere.

The nvim snippet I use in my init.lua to setup ccls to work in that scenario is:

    vim.lsp.config('ccls', {
        init_options = {
            compilationDatabaseDirectory = 'build',
        },
    })
    vim.lsp.enable('ccls')

My actual config does also contain a capabilities = ... argument that forwards the default_capabilities() from nvim-cmp, but you get the point. I hope that helps in case you're curious to give neovim another spin.

davvid

9 ay öncediscuss

> upon further thought, I don't like having to move my hand to the arrow keys

ctrl-n and ctrl-p should let you select next and previous from the autocomplete menu while avoiding the arrow keys.

davvid

5 yıl öncediscuss

There's an ongoing effort to rework core Git so that the hash implementation can be swapped out for eg. SHA256. [1]

jGit is actually a separate project from core Git, but once it gets adopted into core Git we can expect that jGit will follow suite, given that it's critical to Gerrit and other projects.

[1] https://lore.kernel.org/git/[email protected]...

davvid

6 yıl öncediscuss

Google threw money at the problem and that didn't help. Lookup the history behind the "Unladen Swallow" project.

Submissions

OpenPGL Becomes an Academy Software Foundation Project

comments