This isn't really like subtree it's like submodules, but for specific files. This could really be useful, you may want to keep track of a specific file in a repo but not need it as a submodule.
Yes, basically this. I think git-fetch-file has been used in some larger projects based on Googling it, so it seems to be different in that it's been vetted by other orgs, but like Mullvad, theirs is built by a corporation.
Submodules aren't perfect and can be really annoying. I tried to avoid them at first.
But if you work with larger projects I think you'll see how they are useful.
For example, some projects might commit their node_modules or composer vendor folder as submodules so that they have an exact snapshot of their dependencies that can be quickly cloned in place and referenced without mixing it with the parent repos source.
Submodules are certainly not the only way to do things with git. Sometimes monorepos or something else makes more sense.
But if you care about maintainability then what are you supposed to do when the majority of your commits are unrelated to your project because you're using git subtree or something similar? Or the majority of your files are also not directly relevant to your project but need to be there?
What about stuff like optional tests or maintenance scripts or even binary dependencies that you want to have closely associated with your project but don't want to clone every time?
My thinking is that the porcelain is incomplete but very open. The way submodules are represented can be added on to.
And the plumbing is consistent enough that you easily script around it.
You should check out the Datalad project to see some really clever usage of submodules.
And the url key can be annoying; I usually try to use relative paths in my .gitmodules folder when possible. You're actually free to use remote helpers and relative paths to get around hard a github url into it.
You can also embed and read arbitrary keys from your .gitmodules file with git-config -f which is really useful. You don't even have to use a .gitmodules file, in theory.
Well indeed. I think the ultimate point is that Git is severely lacking here. There are clear use cases (you listed some) that drive people to submodules or LFS, but they are both shitty solutions.
We need Git (or something else) to provide a third solution that actually works. I'm really hoping that JJ realises that this is a problem that needs to be solved but I'm not holding my breath.
I think submodules are good enough for what they do and there's room in Git's model for forward development and it's also flexible enough that third party tools can piggyback on it.
Like Git in general it's a bit of a pain till you practice with it more.
Git can do some amazing stuff, I use it for data as well as code.
FYI A submodule doesn't have to use a gitfile and a corresponding `$GIT_DIR/modules/<name>` and there are good reasons not to. As long as the submodule has a '.git' it can be a symlink, or regular .git directory for a self contained embedded repo. You can still use the same gitlink in the parent repo representing it's commit id and git will still manage it.
If I have a 20GB submodule I'd usually just do a `git clone <url> <path> && git submodule add <path>` and it will be treated the same by git. But now I can just delete it and it's purged. And it is more portable less fragile in some ways because it's not de-referencing a gitfile. I prefer my repos to be more bottom-heavy and to not clog my modules folder.
I have a rough script that's the inverse of `git submodule absorbgitdirs` but it's a bit fragile.
It would be cool if there was some plumbing to expose this a bit more.
The few times I've wanted to completely rearrange a repo, It's been enough just make a backup branch and then dump the log from there and pull what I want.
I have script somewhere I think it's called git-cherry-replace, which soft resets a commit id and copies the commit message and optionally populates GIT_COMMITTER_DATE and whatnot.
What I described is probably simple enough that an LLM can implement it.
But unless you're trying to retroactively reconstruct something to preserve the exact meaning, you should consider whether a rebase even makes sense.
I used bluez and bash to lock xscreensaver using some very minimal bash. It wasn't my idea I believe people on the Gentoo forums were doing it.
But you can just loop over something like `hcitool rssi "$MAC"` and project it somewhere, there's a variety of ways.
I like using dunstify with the -p option to persist on screen.
I think it's really impressive what these agents can do, but you should also consider whether you're asking it to burn tokens reinventing the wheel for you, or making a pretty wrapper around a wrapper.
People who don't know things are usually very impressed by solutions that LLMs come up with. I saw one recently that was very impressed that their chosen LLM took screenshots of their vibe coded game to check results, when it's clear from what they were saying the LLM could've literally just read the framebuffer instead, and that's trivial to set up.
I wish more were done to push back against this consolidation of power by these platforms.
We're like frogs that have been stoking the fuel of our own pot.
It used to be that DRM was considered to be in conflict with the browser, because it was not acting on behalf of the user. If you must have DRM, then it is on the platform to shoehorn it in through an external plugin, like Silverlight.
When Firefox adopted EME extensions, I knew it was the beginning of the end; they were rolling out the red carpet for DRM. If we make DRM a switch that can simply be thrown, then it will become the norm, not the exception. And there have been proposals for years to DRM fonts and other absurdities. If a company insists on using DRM, then they should have to shoulder the burden of doing something that a browser was never support to support.
The nightmare that we're racing toward is you will only be permitted to cache a trickle of video at a time and your TPM attestation hardware must include a token in every HTTP request. Your browser will just be a software cablebox.
They aren't happy about URLs either and would love to require that if you want to share a reference to something, you have to do it on their terms, like generating a url in their app with a hash that expires and limited in how many times it can be viewed. I'm sure influencers will still have the privilege of unlimited sharing.
They've been slowly rolling this infrastructure out for the last decade. These are not isolated inconveniences, these are coffin nails.
> The alternative is that people complain "netflix doesn't work on firefox", switch to chrome instead, which is even worse.
So what if users complain? How is it better for Firefox to do something bad just because Google is doing something bad?
Firefox is supposed to provide an alternative to what's out there. Firefox also didn't support some popular proprietary Internet Explorer features, and they never attempted to. For a time, much of MySpace didn't work as well in Firefox. But I'm glad that Firefox didn't cave, even if some users complained that they couldn't make the scrollbars neon green or make music autoplay.
Not letting Microsoft or Google dictate how they implement a web browser worked out really well for them.
Chasing proprietary platforms has ruined them.
At the time EME was adopted Firefox was much more popular, I think 20% back in 2012. Video platforms were using Silverlight for DRM. There's a good chance that EME would not have gotten off the ground if Mozilla didn't embrace it, or at least not as quickly.
Mozilla should have taken a stand and refused to support EME when they had the chance. They would be better off than they are now. And there's a good chance Netflix would not have thrown away a double digit percentage of subscribers.
Instead they embraced DRM and now they have nothing.
That's almost certainly their rationale, bit I'm not convinced it's sound. Firefox's market share is pretty dire anyway, and many people watch Netflix through phones and tv apps now, rather than their actual browser, I wouldn't be surprised if it wasn't an issue at all.
I have never thought of this and it's brilliant. I should definitely be able to whip up a relatively simple script for tagging arbitrary files with arbitrary tags. I was wondering how to achieve something like this for backup purposes and this should make it a breeze.
If you are iterating over a lot of files, a read while loop can be a major bottleneck. As long as you use the null options from find and pipe into xargs, you should be safe with any filename.
I've found it can reduce minutes down to seconds for large operations.
If you have to process a large number of files, you can let xargs minimize the number of times a program is run, instead of running it once per file.
Something like:
# Set the setgid bit for owner and group of all folders
find . -type d -print0 | xargs -0 chmod g+s
# Make the targets of symlinks immutable
find . -type l -print 0 | xargs -0 readlink -z | xargs -0 chattr +i
Way faster.
But there are lots of caveats. Make sure your programs support it. Maybe read the xargs man page.
Personally I skip the middleman when I can with "find ... -exec cmd {} +"
find . -type d -exec chmod g+s {} +
Or even minimise arguments by including a test if the chmod is even needed:
find . -type d \! -perm -g=s -exec chmod g+s {} +
I actually have a script that fixes up permissions, and I was delighted to fit it in a single find invocation which only performs a single stat() on each file in the traversal, and only executes chown/chmod at all for files that need change:
I really wish they would not do that.
The best thing you can do to make your app trustworthy and friendly is to adhere to the host operating system UI guidelines and expectations.
Nobody wants your unique take on the checkbox or textarea please.
reply