I currently have a TUI addiction. Each time I want something to be easier, I open claude-code and ask for a TUI. Now I have a git worktree manager where I can add/rebase/delete. As TUI library I use Textual which claude handles quite well, especially as it can test-run quite some Python code.
That sounds like a complete waste of time and tokens to me, what is the benefit? So each time you do something, you let Claude one shot a tui? This seems like a waste of compute and your time
On the contrary. Once these tools exist they exist forever, independently of Claude or a Claude Code subscription. IMO this is the best way to use AI for personal use.
They said each time they want something to be easier, not each time they do something. And they didn’t mention it has to be one-shot. You might have read too quickly and you’ve responded to something that didn’t actually exist.
Now that I think about it, if Claude can put most useful functions in a TUI and make them discoverable (show them in a list), than this could be better than asking for one-liners (and forgetting them) every single time.
The amount of little tools I'm creating for myself is incredible, 4.6 seems like it can properly one/two shot it now without my attention.
Did you open source that one? I was thinking of this exact same thing but wanted to think a little about how to share deps, i.e. if I do quick worktree to try a branch I don't wanna npm i that takes forever.
Also, if you share it with me, there's obviously no expectations, even it's a half backed vibecoded mess.
If I'm understanding the problem correctly, this should be solved by pnpm [1]. It stores packages in a global cache, and hardlinks to the local node_packages. So running install in a new worktree should be instant.
Testing. If you share something you've tested and know works, that's way better than sharing a prompt which will generate untested code which then has to be tested. On top of that it seems wasteful to burn inference compute (and $) repeating the same thing when the previous output would be superior anyway.
That said, I do think it would be awesome if including prompts/history in the repos somehow became a thing. Not only would it help people learn and improve, but it would allow tweaking.
I’ve been wanting similar but have instead been focused on GUI. My #1 issue with TUI is that I’ve never liked code jumps very smooth high fps fast scrolling. Between that and terminal lacking variable font sizes, I’d vastly prefer TUIs, but I just struggle to get over those two issues.
I’ve been entirely terminal based for 20 years now and those issues have just worn me down. Yet I still love terminal for its simplicity. Rock and a hard place I guess.
Terminal User Interface, contrasting with a Graphical User Interface (GUI). Most often applied to programs that use the terminal as a pseudo-graphical canvas that they draw on with characters to provide an interactive page that can be navigated around with the keyboard.
Really, they're just a GUI drawn with Unicode instead of drawing primitives.
Like many restrictions, limiting oneself to just a fixed grid of colored Unicode characters for drawing lends itself to more creative solutions to problems. Some people prefer such UIs, some people don't.
I prefer tui's for two reasons.
1. Very used to vi keybindings
2. I like low resources software. I love the ability to open the software in less than a second in a second do what I needed using vi motions. And close it less than a second.
Some people will be like you save two seconds trying to do something simple. You lose more time building the tool than you will use it in your life.
It's not about saving time. It's about eliminating the mental toll from having to context switch(i know it sounds ai, reading so much ai text has gotten to me)
That’s an excellent way to explain it. I’m already in the shell doing stuff. Whenever I can stay there without sacrificing usability, it’s a big boost.
Peoples definitions will be on a gradient, but its somewhere between CLI (type into a terminal to use) and GUI (use your mouse in a windowing system), TUI runs in your terminal like a CLI but probably supports "graphical widgets" like buttons, bars, hotkeys, panes, etc.
TUI is peak UI, anyone who disagrees just don't get it. Every program listens to the same keybindings, looks the same and are composable to work together. You don't get that clicking buttons with the mouse. It's built to get the work done not look pretty.
It's definitely an acronym that got popular in the last year or so, though I'm sure there are people out there who will pretend otherwise. I've been in the industry 15+ years now and never heard it before. Previously it was just UI, GUI, or CLI.
It's gotten more popular for sure, but it's definitely been around a long time. Even just on HN there have been conversation about gdb tui ever since I've been here (starting browsing HN around 2011). For anyone who works in embedded systems it's a very common term and has been since I got into it in 2008-ish. I would guess it was much more of a linux/unix user thing until recently though, so people on windows and mac probably rarely if ever intersected with the term, so that's definitely a change. Just my observations.
As someone who came up using Borland's Turbo Pascal, Turbo C, and Turbo Vision (their OOP UI framework), it was called CUI (character-based user interface) to distinguish from GUI, which became relevant as Windows became dominant.
I never heard "TUI" until the last few years, but it may be due to my background being Microsoft-oriented.
My friends and I have been actively in the "CLI/TUI" since middle school. Anyone tinkering on linux that used tiling window managers is already very familiar with the domain.
Different type of creator, different type of bugs. I'd assume a human giving me a way to delete merged branches has probably had the same issue, solved the same problem and understands unspecified context around the problem (e.g protect local data). They probably run it themselves so bugs are most likely to occur in edge cases around none standard use as it works for them.
Ais are giving you what they get from common patterns, parsing documentation etc. Depending what you're asking this might be an entirely novel combination of commands never run before. And depending on the model/prompt it might solve in a way any human would balk at (push main to origin, delete .git, re-clone from origin. Merged local branches are gone!)
It's like the ai art issues - people struggle with relative proportions and tones and making it look real. Ai has no issues with tones, but will add extra fingers or arms etc that humans rarely struggle with. You have to look for different things, and Ai bugs are definitely more dangerous than (most) human bugs.
(Depends a little, it's pretty easy to tell if a human knows what they're talking about. There's for sure humans who could write super destructive code, but other elements usually make you suspicious and worried about the code before that)
It makes a difference whether an AI or a human wrote it. AIs make more random, inconsistent errors or omissions that a human wouldn’t make. AIs also don’t dog-feed their code the way human developers of tools usually do, catching more errors or unfit/missing logic that way.
If that's something you're worried about, review the code before running it.
> don't you get anxiety "what if there's an error in tui code and it would mess up my git repo"?
I think you might want to not run untrusted programs in an environment like that, alternatively find a way of start being able to trust the program. Either approaches work, and works best depending on what you're trying to do.
Depends. If I was the one coming up with the implementation anyways, it's basically just the "coding" part that was replaced with "fingers hitting keyboard" and "agents writing to disk", so reviewing the code certainly is faster, you just have to "check" it, not understand it from scratch.
If we're talking receiving random patches where first you have to understand the context, background and so on, then yeah I agree, it'll take longer time probably than what it took for someone to hammer with their fingers. But again, I'm not sure that's how professionals use LLMs right now, vibe-coding is a small hyped world mostly non-programmers seem to engage in.
> you just have to "check" it, not understand it from scratch.
How can you "check" that which you don't "understand"?
> I'm not sure that's how professionals use LLMs right now
I'm a professional and I can tell you how I use LLMs: I write code with their assistance, they don't write code for me.
The few times I let Claude or Copilot loose, the results were heartbreaking and I spent more time reviewing (and then discarding) the code than what it took me to later write it from scratch.
> How can you "check" that which you don't "understand"?
??? I do understand, since I literally just instructed it, how would I otherwise? I'm not letting the LLM do the design, it's all me still. So the "understand" already exists before the LLM even finished working.
> I'm a professional and I can tell you how I use LLMs: I write code with their assistance, they don't write code for me.
Hey, welcome to the club, me too :) I don't write code, I write English prose, yet nothing is vibe coded, and probably I'll end up being able to spend more time than you thinking about the design and architecture and how it fits in, because actual typing is no longer slowing me down. Yet again, every line is reviewed multiple times.
It's more about the person behind the tools, than the tools themselves I think ultimately. Except for Copilot probably, the times I've tried it I've just not been able to produce code that is even slightly up to my standards. It's a breeze with Codex though (5.2), and kind of hit and miss with Claude Code.
Maybe they are able to write unambiguous fully specified English prose? But yeah there should tell the world then, we others desperately don't know how to do that.
I'm not GP, but I have backups, plus I always make sure I've committed and pushed all code I care about to the remote. I do this even when running a prompt in an agent. That goes for running most things actually, not just CC. If claude code runs a git push -f then that could really hurt, but I have enough confidence from working with the agents that they aren't going to do that that it's worth it to me to take the risk in exchange for the convenience of using the agent.
I push my branches daily, so I wouldn't lose that much work. If it breaks then I ask it to fix it.
But I do quickly check the output what it does, and especially the commands it runs. Sometimes it throws all code in a single file, so I ask for 'good architecture with abstractions'.
I see this regularly: "I use GitHub to backup my local repos."
If `gh repo ...` commands get run you can lose everything instantly. You can force push and be left with a single blank commit on both sides. The agent has full control of everything, not just your local data.
Just set up Rclone/restic and get your stuff into a system with some immutability.
Force pushing doesn't actually remove anything from the remote repository, only changes some references for which commits the branches point to. Plus, any forks on github will be completely unaffected. It's not perfect, since Github doesn't seem to offer any history of such reference alterations (a la the reflog), but it's still a valuable offsite backup from a developer's perspective.
Okay, fair enough re force pushing (though `gh repo delete` is still an option). I suppose for a sufficiently active codebase copies of it will exist elsewhere. Just seems odd to me that people aren't backing up anything else on their computers otherwise they could trivially just include their git-based projects.
It's a git repo. What's sort of mess-ups are you worried about that you can't reflog your way out of (or ask claude code to fix)? It's certainly possible to lose uncommitted work, but once it's been committed, unless claude code goes and deletes .git entirely (which I've had codex do, so you'd better push it somewhere), you can't lose work.
In the case of Git, I can warmly recommend Magit as a TUI. Not only does it make frequent operations easier and rare operations doable -- it also teaches you Git!
I change themes just often enough to completely forget how to do it and also forget whatever other adjustments I had to make to it all work. And like... is my config versioned somehow? This is a long way to say, Thank You for inspiring me to look at all that stuff again!
This feels like gatekeeping someone sharing something cool they've recently learned.
I personally lean more towards the "let's share cool little productivity tips and tricks with one another" instead of the "in order to share this you have to meet [entirely arbitrary line of novelty/cleverness/originality]."
But each to their own I suppose. I wonder how you learned about using xargs? Maybe a blog-post or article not dissimilar to this one?
No I agree with you. This whole aura of "well IIIII knew this and YOUUUUU didnt" needs to die. I get that it's sometimes redundant and frustrating to encounter the same question a few times... but there's always new people learning in this world, and they deserve a chance to learn too.
Why do people constantly have to be looking for any way to justify their sense of superiority over others? Collaborative attitudes are so much better for all involved.
I don't think there's anything wrong with sharing something cool, even if it's trivial to other people. The problem is framing a blog post with "ooh this was buried in the secret leaked CIA material".. and then the reader opens it to find out it's just xargs. It feels very clickbaity. Akin to "here's one simple trick to gain a treasure trove of information about all the secret processes running on your system!!" and it's just ps.
Lots of negative sentiment on your comment, but I was going to write the same. Hopefully AI won’t make us forget that good command line tools are designed to be chained together if you want to achieve something that’s perhaps too niche as a use case to make it into a native command. It’s worth learning about swiss army utilities like xargs that make this easy (and fun)
What nauseous sentiment. I recommend "The CIA as Organized Crime: How Illegal Operations Corrupt America and the World" by Douglas Valentine, ISBN 978-0997287011. One of the most evil organizations ever to have existed.
Speaking of user friendliness of git UI. I am working on a revision control system that (ideally) should be as user friendly as Ctrl+S Ctrl+Z in most common cases. Spent almost a week on design docs, looking for feedback (so far it was very valuable, btw)
Have you tried Jujutsu? If you want to make a better VCS, your baseline should be that, in my opinion, because it already deals with a lot of the Git pain points whilst be able to read and publish to Git repositories.
The idea of using git as a blob storage and building entire new machinery on top is definitely a worthy one. At this point though, the de-facto baseline is no doubt git. If git as a store withstands the abuse of jj and jj becomes the industry standard, then I would agree with you. Also, at that point they may drop git backend entirely just because of price/performance discrepancy. git is overweight for what it does, if they make it do only the bottom 20%, then things will get funny.
Still, many oddities of git are inevitable due to its underlying storage model, so it makes sense to explore other models too.
I've had essentially that - if a bit fancier to accept an optional argument as well as handle common "mainline" branch names - aliased as `git lint` for a while:
The main issue with `git branch --merged` is that if the repo enforces squash merges, it obviously won't work, because SHA of squash-merged commit in main != SHA of the original branch HEAD.
What tools are the best to do the equivalent but for squash-merged branches detections?
Note: this problem is harder than it seems to do safely, because e.g. I can have a branch `foo` locally that was squash-merged on remote, but before it happened, I might have added a few more commits locally and forgot to push. So naively deleting `foo` locally may make me lose data.
Not just squash merges, rebase-merges also don't work.
> What tools are the best to do the equivalent but for squash-merged branches detections?
Hooking on remote branch deletion is what most people do, under the assumption that you tend to clean out the branches of your PRs after a while. But of course if you don't do that it doesn't work.
`Out-GridView` gives a very simple dialog box to (multi) select branch names I want to mark finished.
I'm a branch hoarder in a squash merge repo and just prepend a `zoo/` prefix. `zoo/` generally sorts to the bottom of branch lists and I can collapse it as a folder in many UIs. I have found this useful in several ways:
1) It makes `git rebase --interactive` much easier when working with stacked branches by taking advantage of `--update-refs`. Merges do all that work for you by finding their common base/ancestor. Squash merging you have to remember which commits already merged to drop from your branch. With `--update-refs` if I find it trying to update a `zoo/` branch I know I can drop/delete every commit up to that update-ref line and also delete the update-ref.
2) I sometimes do want to find code in intermediate commits that never made it into the squashed version. Maybe I tried an experiment in a commit in a branch, then deleted that experiment in switching directions in a later commit. Squashing removes all evidence of that deleted experiment, but I can still find it if I remember the `zoo/` branch name.
All this extra work for things that merge commits gives you for free/simpler just makes me dislike squash merging repos more.
Depends on your workflow, I guess. I don't need to handle that case you noted and we delete the branch on remote after it's merged. So, it's good enough for me to delete my local branch if the upstream branch is gone. This is the alias I use for that, which I picked up from HN.
3. grep upstream git log for a commit with the same commit subject
Has some caveats, like
if upstream's commit was amended or the actual code change is different, it can have a false positive, or
if there are multiple commits on your local branch, only the top commit is checked
I recently revised my script to rely on (1) no commits in the last 30 days and (2) branch not found on origin. This is obviously not perfect, but it's good enough for me and just in case, my script prompts to confirm before deleting each branch, although most of the time I just blindly hit yes.
I also set mine up to run on `git checkout master` so that I don't really have to think about it too hard -- it just runs automagically. `gcm` has now become muscle memory for me.
IIRC, you can do git branch -D $(git branch) and git will refuse to delete your current branch. Kind of the lazy way. I never work off of master/main, and usually when I need to look at them I checkout the remote branches instead.
In Github it needs to be explicitly configured (Settings > General > Delete head branches after merging), Gitlab is the same.
A lot of my developer colleagues don't know how git works, so they have no idea that "I merged the PR" != "I deleted the feature branch". I once had to cleanup a couple repositories that had hundreds of branches spanning back 5+ years.
Nowadays I enforce it as the default project setting.
`--prune` will delete your local copies of the origin's branches (e.g. `origin/whatever`). But it won't delete your local branches (e.g. `whatever` itself). So PRs that you've worked on or checked out locally will never get deleted.
> Dont most git instances, like github, delete branch after a PR was merged, by default?
By default, I don't think so. And even if the branch is deleted, objects can still be there. I think GitLab has a "Clean stale objects" thing you can trigger, I don't seem to recall ever seeing any "Git Maintenance" UI actions on GitHub so not sure how it works there.
I recently let copilot create a document with a few helpful git commands and that particular one was the one it came with as solution for exactly this case.
I do `gb` (probably "git branch" when I set that up) which apparently is an alias to `git for-each-ref --sort=-committerdate refs/heads/ --format='%(refname:short)' | tac`, displays a list with the latest changed branch at the bottom. Remove the `| tac` for the reverse order.
Yes, I run something like this (PowerShell borks out unless there are double quotes inside the single quotes) in a short script when I need to review available branches:
I include a [month][day][hour][minute]-[git hash] prefix as enough info to see when branches were last updated and grab them when I make a mistake creating the branch from the wrong parent or want to cherry-pick.
This isn't exactly the same but I've been using git-recent [0] (with `gr` alias) for many years. It sorts branches based on checkout order (which is what I usually need when switching between branches) and allows to easily choose a branch to checkout to.
I have an image of running his command, 'ciaclean', and a black van turnes up with a bunch of agents in coveralls, brandishing rolls of polyethylene sheeting and drums of acid.
It won't delete unmerged branches by default. The line with the marker for the current branch throws an error but it does no harm. And I just run it with `develop` checked out. If I delete develop by accident I can recreate it from origin/develop.
Sometimes I intentionally delete develop if my develop branch is far behind the feature branch I'm on. If I don't and I have to switch to a really old develop and pull before merging in my feature branch, it creates unnecessary churn on my files and makes my IDE waste time trying to build the obsolete stuff. And depending how obsolete it is and what files have changed, it can be disruptive to the IDE.
I have a cleanup command that integrates with fzf. It pre selects every merged branch, so I can just hit return to delete them all. But it gives me the opportunity to deselect to preserve any branches if I want. It also prunes any remote branches
I've got a few aliases that integrate with fzf like an interactive cherry pick (choose branch, choose 1 or more commits), or a branch selector with a preview panel showing commits to the side. Super useful
The article also mentions that master has changed to main mostly, but some places use develop and other names as their primary branch. For that reason I always use a git config variable to reference such branches. In my global git config it's main. Then I override where necessary in any repo's local config eg here's an update command that updates primary and rebases the current branch on top:
# switch to primary branch, pull, switch back, rebase
update = !"git switch ${1:-$(git config user.primaryBranch)}; git pull; git switch -; git rebase -;"
Hmm that might be nice actually. I like not conflating those two things, but as you say if the repo is already init'd then there's no chance it'll be used for the wrong purpose.
In any case the main thrust was just to avoid embeddings assumptions about branch names in your scripts :)
It simply occurred to me that if your `user.defaultBranch` is set to e.g `trunk` then presumably when you `git init` you also want it to create a `trunk` branch, ergo `init.defaultBranch` would be set to the same value, ergo... irrespective of naming, could they actually be the same thing?
I can see a case for keeping them apart too though.
`Out-GridView` gives you a quick popup dialog with all the branch names that supports easy multi-select. That way you get a quick preview of what you are cleaning up and can skip work in progress branch names that you haven't committed anything to yet.
The leaked material from which this came was described as being from 2017, which makes that the latest this could have been written - GitHub only changed the default for new repos in October of 2020, and there had only been consensus building around the switch for a couple of years beforehand.
If something this natural requires several lines of bash, something is just not right. Maybe branches should go sorted by default, either chronologically or topologically? git's LoC budget is 20x LevelDBs or 30% of PostgreSQL or 3 SQLites. It must be able to do these things out of the box, isn't it?
Yeah "too many lines of bash" is like "too many clicks needed". Actually since there are aliases, it's more like "too many clicks needed to add it to favourites and then it needs a single click"
I used to think this but spending some time learning about xargs (hell even for loops) makes me feel like this is trivial enough to stuff somewhere.
Lots of people have mentioned awkward use cases where decisions have to be made. A built in command would have to confront those and it might not be easy
The use of init.defaultBranch here is really problematic, because different repositories may use a different name for their default, and this is a global (your home directory scope) setting you have to pre-set.
I have an alias I use called git default which works like this:
default = !git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'
then it becomes
..."$(git default)"...
This figures out the actual default from the origin.
I have a global setting for that. Whenever I work in a repo that deviates from that I override it locally. I have a few other aliases that rely on the default branch, such as “switch to the default branch”. So I usually notice it quite quickly when the value is off in a particular repo.
I work at a company that was born and grew during the master->main transition. As a result, we have a 50/50 split of main and master.
No matter what you think about the reason for the transition, any reasonable person must admit that this was a stupid, user hostile, and needlessly complexifying change.
I am a trainer at my company. I literally teach git. And: I have no words.
Every time I decide to NOT explain to a new engineer why it's that way and say, "just learn that some are master, newer ones are main, there's no way to be sure" a little piece of me dies inside.
Why does your company not migrate to one standard? Github has this functionality built in, and it's also easy enough to do with just git.
I'm personally a huge fan of the master-> main changejus5t because main is shorter to type. Might be a small win, but I checkout projects' main branches a lot.
It's extremely obvious that "main" is more ergonomic. It's sad that we're so resistant to change (regardless of how valid you think the initial trigger was)
No, actually, zero people 'must admit' that it was a stupid, user hostile and needlessly complexifying change.
I would say any reasonable person would have to agree that a company which didn't bother to set a standard for new repos once there are multiple common options is stupid, user hostile and needlessly complexifying. And if the company does have a standard for new repos, but for some reason you don't explain that to new engineers....
There was only a single standard before, so there was no reason why a company should make any company specific standard. The need for companies to make a standard only exists, since the master to main change, because now there are two standards.
Except git init still creates branches named master without configuration (although with a warning), which will only change in 3.0 for obvious reasons, and tons of people (including me) still use master, and old projects don't just vanish.
I love the arguments where you tell me what I “must admit”.
I simply don’t, therefore your entire point is meaningless.
I’m sorry that something so inconsequential irked you so much. Maybe you need to read a book about git if this stumped you bad enough to want to voice your upset about it years later?
I’d consider yourself lucky that everything else is going so well that this is what’s occupying you.
I needed that exact functionality and Claude code and ChatGPT consistently showing this same exact combo CLI receipt with the simple prompt "how to do use CLI to remove merged branch locally."
I use `master` in all my repos because I've been using it since forever and it never has once occurred to me "oh shit I better change it to `main` this time in case `master` may offend somebody some day. Unfortunately, that's the last thing on my mind when I'm in programming mode. Now that everything is `master`, maybe it is just a simple git command to change it to `main`. But, my fear is it'll subtly break something and I just don't have enough hours left in my life to accept yet unknown risk that it'll cost me even more hours, just to make some random sensitive developer not get offended one day.
At Meta, when this mass push for the rename happened across the industry, a few people spent nearly the full year just shepherding the renaming of master to main, and white box/black box to allowlist/blocklist.
This let them claim huge diff counts and major contributions to DEI and get promos.
Seems like a bad faith question, unfortunate that it was asked multiple times. Blacklist is derived from a definition where black means "evil, bad, or undesirable". When you say that ink is black, you're using a different definition, which relates to color. I don't know if I see the objection to blackbox, which uses a definition of "unknown". Personally, I think the harm is small but I look to people of color for guidance and prefer the more descriptive deny-list where I can. Cuts down on possible confusion for non-native English speakers too.
The irony is that the term "Black" was precisely chosen by Black civil rights activists in the 1960s. This wasn't a term given by white people, it was specifically chosen by Blacks, because of its negative connotations. They wanted to embrace its negative connotations and turn it on its head, and that's where terms like "Black is beautiful" came from. They didn't want to be ashamed of it, that's why they embraced it. Black was not a term of shame, it was a term of power.
Now, the left wing activists have turned it on its head again, and now saying that the term "black" is shameful and racist. It's bizarre how ignorant people are who say the term "blacklist" is racist.
Blacklist and Whitelist come from the behaviour of light on coloured surfaces. A black surface absorbs all light, a white reflects it. There is also Graylist.
I don't know of any connotation of black meaning "evil, bad, or undesirable". If anything black means "missing or vanished". Maybe that is different in your culture, but I never heard of it until now. Tons of things in everyday life are black including the most letters, signs and a lot of devices. The only thing that comes to my mind is tooth decay or pestilence, but that is hardly anything connotated with the colour per se.
A quick web search for "define black" and "etymology blacklist" readily finds "from black (adj.), here indicative of disgrace, censure, punishment (a sense attested from 1590s, in black book)" and several similar results. But I didn't immediately see an etymology based on absorbing light.
I'd be curious to see a regional reference that shows an absorb/reflect etymology.
Also, git's "master" branch is named after a master recording or master copy, the canonical original from which duplicates are made. There is literally no reason for it be offensive except for those who retroactively associate the word with slavery.
Yeah, with replica it made a little sense. Was still silly, but at least the official master/slave terminology actually didn't fully make sense either... So the replica rebrand felt justified to me.
With git it was basically entirely driven by SJW that felt empowered by people accepting the replica rebrand
imo the `main` thing was mostly driven by people trying to appease the social justice crowd without understanding much about the movement. Its a bit of woo in my mind because there are still systemic injustices out there that are left uncontested, and using main doesn't really contest anything substantial.
I don't really care what the default branch is called tho so I'm willing to play along.
I'm fully on-board with not using master-slave terminology. I work in the embedded space where those terms were and still are frequently used, and I support not using them any more. But I've been using git pretty much since it was released and I've never heard anyone refer to a "slave repo" or "slave branch". It's always been local repo, local branch, etc. I fully believe these sorts of digital hermeneutics (e.g. using a 26-year-old mailing list post to "prove" something, when actual usage is completely different) drive division and strife, all because some people want to use it to acquire status/prestige.
Then does simply performing a search on bitkeepers documents for "slave" then automatically imply any particular terminology "came from bitkeeper?"
Did they take it from bitkeeper because they prefer antiquated chattel slavery terminology? Is there any actual documents that show this /intention/?
Or did they take it because "master" without slave is easily recognizable as described above which accurately describes how it's _actually_ implemented in git.
> But, my fear is it'll subtly break something and I just don't have enough hours left in my life to accept yet unknown risk that it'll cost me even more hours,
Yeah, it's not like 99% of the world has already switched from master to main already (without any major problems) ...
You'll find CI/CD automation probably needs to be updated. (Triggering different actions when merges to the default branch happen, or perhaps just deployments.)
These are the kinda local things that the parent was probably referring to.
Im just tuning out of the whole master vs main discussion. I use whatever is the default branch name of my current project OR what git init gives me. When / if git init produces a default branch named main, i'll use that.
In current times, there will be more people offended that some prefer to use "main" rather than "master", than people that will be offended if "master" is used
Haven't got enough hours to type fewer characters, but have got plenty of time to go karma-fishing about it on an almost barely tangentially relevant HN thread. Cool.
gh-poi plugin is a must if you manage a lot of github pr and want to easily clean the branch attached to it when pr is merged https://github.com/seachicken/gh-poi
I keep a command `git-remove-merged`, which uses `git ls-remote` to see if the branch is set up to track a remote branch, and if it is then whether the remote branch still exists. On the assumption that branches which have had remote tracking but no longer do are either merged or defunct.
What's wrong with just deleting the whole folder and clone repo and whatever branch you're interested in? In any case it's not an urgent thing. You don't have to do this mid-work, you can wait until you push most stuff and then rm && git clone.
The only case in which this wouldn't work is when you have a ton of necessary local branches you can't even push to remote, which is a risk and anti-pattern per se.
doesn't your precious stash deserve an external folder or remote branch, in any case? the local repo is always a risk, so many things can ruin it.
also, you only need to clean up like once a year, it's by definition a rare operation. A ton of branches doesn't grow overnight.
In addition to the already mentioned stash, which I often have stuff in for months, there is also all the commits not reachable from any branch and all the history of any branch I ever created. Throwing all that away would be quite a disruptive change for me.
I want to point out explicitly that .git config supports aliases, so in .gitconfig put an [alias] section, and in that you can put
ciaclean = "!alias ciaclean='git branch --merged origin/main | grep -vE "^\s(*|main|develop)" | xargs -n 1 git branch -d'"
so then it's `git ciaclean` and not bare `ciaclean` which imo is cleaner.
The Git command is whatever, pretty basic and stuff i have done forever but i am glad i clicked because ended up going down the rabbithole of the Wikileaks it was sourced from
Some unhinged stuff there. Like the CIA having a project called "Fine Dining" which was basically a catalog of apps that could be put on a USB drive to hide malicious code.
A case officer picks a cover app from a list of 24: VLC, Chrome, Notepad++, 2048, Breakout. Plug in the USB. Cover app opens. Exfiltration runs silently behind it. Target walks back in and the officer can just say "oh was just playing some games on this machine"
If someone else is messing with my computer, it doesn't really matter if he claims that he only played games. They could have done what ever else and still opened the game at the end, this is just a way to make that process smoother.
whazor | a day ago
lionkor | a day ago
MarsIronPI | a day ago
duneisagoodbook | a day ago
morissette | a day ago
htnthrow11220 | a day ago
bmacho | a day ago
Maybe I'll try using small TUI too.
Trufa | a day ago
Did you open source that one? I was thinking of this exact same thing but wanted to think a little about how to share deps, i.e. if I do quick worktree to try a branch I don't wanna npm i that takes forever.
Also, if you share it with me, there's obviously no expectations, even it's a half backed vibecoded mess.
elliotbnvl | a day ago
CalebJohn | a day ago
[1]: https://pnpm.io/motivation
SauntSolaire | a day ago
freedomben | a day ago
That said, I do think it would be awesome if including prompts/history in the repos somehow became a thing. Not only would it help people learn and improve, but it would allow tweaking.
NetOpWibby | a day ago
unshavedyak | a day ago
I’ve been entirely terminal based for 20 years now and those issues have just worn me down. Yet I still love terminal for its simplicity. Rock and a hard place I guess.
whazor | a day ago
Nix helps Claude a lot with dependencies, it can add stuff and execute the flake as well.
I will come back to you with project itself.
firesteelrain | a day ago
ses1984 | a day ago
Bjartr | a day ago
Really, they're just a GUI drawn with Unicode instead of drawing primitives.
Like many restrictions, limiting oneself to just a fixed grid of colored Unicode characters for drawing lends itself to more creative solutions to problems. Some people prefer such UIs, some people don't.
Muvasa | a day ago
Some people will be like you save two seconds trying to do something simple. You lose more time building the tool than you will use it in your life.
It's not about saving time. It's about eliminating the mental toll from having to context switch(i know it sounds ai, reading so much ai text has gotten to me)
irl_zebra | a day ago
This broke my brain! Woah!
kstrauser | a day ago
1718627440 | 13 hours ago
criddell | a day ago
Or mouse / trackpad.
I really haven't seen anything better for making TUIs than Borland's Turbo Vision framework from 35ish years ago.
GCUMstlyHarmls | a day ago
Peoples definitions will be on a gradient, but its somewhere between CLI (type into a terminal to use) and GUI (use your mouse in a windowing system), TUI runs in your terminal like a CLI but probably supports "graphical widgets" like buttons, bars, hotkeys, panes, etc.
giglamesh | a day ago
allarm | a day ago
worksonmine | a day ago
booleandilemma | a day ago
freedomben | a day ago
snozolli | a day ago
I never heard "TUI" until the last few years, but it may be due to my background being Microsoft-oriented.
One of the only references I can find is the PC Magazine encyclopedia: https://www.pcmag.com/encyclopedia/term/cui
0x1ch | a day ago
layer8 | a day ago
hattmall | a day ago
rw_panic0_0 | a day ago
sclangdon | a day ago
phailhaus | a day ago
coldtea | 21 hours ago
hennell | a day ago
Ais are giving you what they get from common patterns, parsing documentation etc. Depending what you're asking this might be an entirely novel combination of commands never run before. And depending on the model/prompt it might solve in a way any human would balk at (push main to origin, delete .git, re-clone from origin. Merged local branches are gone!)
It's like the ai art issues - people struggle with relative proportions and tones and making it look real. Ai has no issues with tones, but will add extra fingers or arms etc that humans rarely struggle with. You have to look for different things, and Ai bugs are definitely more dangerous than (most) human bugs.
(Depends a little, it's pretty easy to tell if a human knows what they're talking about. There's for sure humans who could write super destructive code, but other elements usually make you suspicious and worried about the code before that)
layer8 | a day ago
embedding-shape | a day ago
If that's something you're worried about, review the code before running it.
> don't you get anxiety "what if there's an error in tui code and it would mess up my git repo"?
I think you might want to not run untrusted programs in an environment like that, alternatively find a way of start being able to trust the program. Either approaches work, and works best depending on what you're trying to do.
kaoD | a day ago
It takes more, not less, time to thoroughly review code you didn't write.
embedding-shape | a day ago
If we're talking receiving random patches where first you have to understand the context, background and so on, then yeah I agree, it'll take longer time probably than what it took for someone to hammer with their fingers. But again, I'm not sure that's how professionals use LLMs right now, vibe-coding is a small hyped world mostly non-programmers seem to engage in.
kaoD | a day ago
How can you "check" that which you don't "understand"?
> I'm not sure that's how professionals use LLMs right now
I'm a professional and I can tell you how I use LLMs: I write code with their assistance, they don't write code for me.
The few times I let Claude or Copilot loose, the results were heartbreaking and I spent more time reviewing (and then discarding) the code than what it took me to later write it from scratch.
embedding-shape | a day ago
??? I do understand, since I literally just instructed it, how would I otherwise? I'm not letting the LLM do the design, it's all me still. So the "understand" already exists before the LLM even finished working.
> I'm a professional and I can tell you how I use LLMs: I write code with their assistance, they don't write code for me.
Hey, welcome to the club, me too :) I don't write code, I write English prose, yet nothing is vibe coded, and probably I'll end up being able to spend more time than you thinking about the design and architecture and how it fits in, because actual typing is no longer slowing me down. Yet again, every line is reviewed multiple times.
It's more about the person behind the tools, than the tools themselves I think ultimately. Except for Copilot probably, the times I've tried it I've just not been able to produce code that is even slightly up to my standards. It's a breeze with Codex though (5.2), and kind of hit and miss with Claude Code.
coldtea | 21 hours ago
If the input is English prose, how is it not "vibe coded"?
1718627440 | 13 hours ago
coldtea | 21 hours ago
Nope, it takes way less. Else PR reviews would take as long as coding, which they obviously don't.
Writing 1000 lines, figuring out the nuances of the domain, fixing bugs, testing, takes way more time that reading and reviewing the resulting code.
Besides, you can even ask another agent to review it. Different brand of agent even.
freedomben | a day ago
ithkuil | a day ago
whazor | a day ago
But I do quickly check the output what it does, and especially the commands it runs. Sometimes it throws all code in a single file, so I ask for 'good architecture with abstractions'.
zenoprax | a day ago
If `gh repo ...` commands get run you can lose everything instantly. You can force push and be left with a single blank commit on both sides. The agent has full control of everything, not just your local data.
Just set up Rclone/restic and get your stuff into a system with some immutability.
tux1968 | a day ago
zenoprax | 23 hours ago
fragmede | a day ago
kevmo314 | 23 hours ago
eulers_secret | a day ago
If nothing else maybe for inspiration
kqr | a day ago
I have a draft here about one aspect of Magit I enjoy: https://entropicthoughts.com/rebasing-in-magit
galbar | a day ago
It also has one for squash-merged branches: gbds
Very useful I've been using them for years
blakesterz | a day ago
gjvc | a day ago
giglamesh | a day ago
parliament32 | a day ago
jimmydoe | a day ago
That says so much about the generation we are in, just don’t go to school but learn math from mafia
vntok | a day ago
skydhash | a day ago
gosub100 | a day ago
SoftTalker | a day ago
gavinray | a day ago
Saying "If you read X book, you'll realize it's a solved problem" IS the information -- the name of the book you need to read
Someone1234 | a day ago
I personally lean more towards the "let's share cool little productivity tips and tricks with one another" instead of the "in order to share this you have to meet [entirely arbitrary line of novelty/cleverness/originality]."
But each to their own I suppose. I wonder how you learned about using xargs? Maybe a blog-post or article not dissimilar to this one?
superxpro12 | a day ago
Why do people constantly have to be looking for any way to justify their sense of superiority over others? Collaborative attitudes are so much better for all involved.
parliament32 | a day ago
audience_mem | a day ago
JasonADrury | 14 hours ago
Calling out clickbait isn't gatekeeping.
ggrab | a day ago
mrexcess | a day ago
oldestofsports | a day ago
throwaway27448 | 5 hours ago
What nauseous sentiment. I recommend "The CIA as Organized Crime: How Illegal Operations Corrupt America and the World" by Douglas Valentine, ISBN 978-0997287011. One of the most evil organizations ever to have existed.
dewey | a day ago
sigio | a day ago
1a527dd5 | a day ago
arusahni | a day ago
2. Enumerate local branches, selecting each that has been marked as no longer having a remote version (ignoring the current branch)
3. Delete the local branch safely
gritzko | a day ago
https://replicated.wiki/blog/partII.html#navigating-the-hist...
oniony | a day ago
gritzko | a day ago
Still, many oddities of git are inevitable due to its underlying storage model, so it makes sense to explore other models too.
jo-m | a day ago
lloeki | a day ago
jakub_g | a day ago
What tools are the best to do the equivalent but for squash-merged branches detections?
Note: this problem is harder than it seems to do safely, because e.g. I can have a branch `foo` locally that was squash-merged on remote, but before it happened, I might have added a few more commits locally and forgot to push. So naively deleting `foo` locally may make me lose data.
masklinn | a day ago
> What tools are the best to do the equivalent but for squash-merged branches detections?
Hooking on remote branch deletion is what most people do, under the assumption that you tend to clean out the branches of your PRs after a while. But of course if you don't do that it doesn't work.
WorldMaker | a day ago
I'm a branch hoarder in a squash merge repo and just prepend a `zoo/` prefix. `zoo/` generally sorts to the bottom of branch lists and I can collapse it as a folder in many UIs. I have found this useful in several ways:
1) It makes `git rebase --interactive` much easier when working with stacked branches by taking advantage of `--update-refs`. Merges do all that work for you by finding their common base/ancestor. Squash merging you have to remember which commits already merged to drop from your branch. With `--update-refs` if I find it trying to update a `zoo/` branch I know I can drop/delete every commit up to that update-ref line and also delete the update-ref.
2) I sometimes do want to find code in intermediate commits that never made it into the squashed version. Maybe I tried an experiment in a commit in a branch, then deleted that experiment in switching directions in a later commit. Squashing removes all evidence of that deleted experiment, but I can still find it if I remember the `zoo/` branch name.
All this extra work for things that merge commits gives you for free/simpler just makes me dislike squash merging repos more.
samhclark | a day ago
laksdjf | a day ago
It prints the results of 3 methods:
1. git branch --merged
2. git cherry
3. grep upstream git log for a commit with the same commit subject
Has some caveats, like if upstream's commit was amended or the actual code change is different, it can have a false positive, or if there are multiple commits on your local branch, only the top commit is checked
arccy | a day ago
de46le | a day ago
Pipe right to deletion if brave, or to a choice-thingy if prudent :)
otsaloma | a day ago
To avoid losing any work, I have a habit of never keeping branches local-only for long. Additionally this relies on https://docs.github.com/en/repositories/configuring-branches...
rtpg | 23 hours ago
Arch-TK | a day ago
schiffern | a day ago
I assume CIA stands for Clean It All.
sammyteee | a day ago
schiffern | 23 hours ago
Clean It All Clean also sounds like a 50s detergent slogan, so it's got that going for it.
plufz | a day ago
stabbles | a day ago
trashymctrash | a day ago
lkbm | a day ago
I think I probably copied this from Stack Overflow close to a decade ago. Seems like a lot of people have very similar variations.
taude | a day ago
Cherub0774 | a day ago
I also set mine up to run on `git checkout master` so that I don't really have to think about it too hard -- it just runs automagically. `gcm` has now become muscle memory for me.
masklinn | a day ago
d0liver | a day ago
dietr1ch | a day ago
PunchyHamster | a day ago
> Since most projects now use main instead of master
some delusions to boot
Sesse__ | a day ago
puzz | a day ago
https://github.com/tkrajina/git-plus
Disclaimer, I'm the author ^^
ihsoy | a day ago
I am not sure under what usecases, you will end up with a lot of stale branches. And git fetch -pa should fix it locally
plqbfbv | a day ago
A lot of my developer colleagues don't know how git works, so they have no idea that "I merged the PR" != "I deleted the feature branch". I once had to cleanup a couple repositories that had hundreds of branches spanning back 5+ years.
Nowadays I enforce it as the default project setting.
nightpool | a day ago
embedding-shape | a day ago
By default, I don't think so. And even if the branch is deleted, objects can still be there. I think GitLab has a "Clean stale objects" thing you can trigger, I don't seem to recall ever seeing any "Git Maintenance" UI actions on GitHub so not sure how it works there.
Izkata | 13 hours ago
This deletes orphaned objects in commits that are unreachable after force-pushes or deleting branches or such, it doesn't delete branches itself.
micw | a day ago
password4321 | a day ago
the_real_cher | a day ago
(not on my computer right now to check)
embedding-shape | a day ago
password4321 | a day ago
rpozarickij | a day ago
[0] https://github.com/paulirish/git-recent
jimnotgym | a day ago
EricRiese | a day ago
git branch | xargs git branch -d
Don't quote me, that's off the top of my head.
It won't delete unmerged branches by default. The line with the marker for the current branch throws an error but it does no harm. And I just run it with `develop` checked out. If I delete develop by accident I can recreate it from origin/develop.
Sometimes I intentionally delete develop if my develop branch is far behind the feature branch I'm on. If I don't and I have to switch to a really old develop and pull before merging in my feature branch, it creates unnecessary churn on my files and makes my IDE waste time trying to build the obsolete stuff. And depending how obsolete it is and what files have changed, it can be disruptive to the IDE.
cowlby | a day ago
mywittyname | a day ago
I have replaced my standard ddg of, "git <the thing i need>" with asking Claude to give me the commands I need to run.
WickyNilliams | a day ago
I've got a few aliases that integrate with fzf like an interactive cherry pick (choose branch, choose 1 or more commits), or a branch selector with a preview panel showing commits to the side. Super useful
The article also mentions that master has changed to main mostly, but some places use develop and other names as their primary branch. For that reason I always use a git config variable to reference such branches. In my global git config it's main. Then I override where necessary in any repo's local config eg here's an update command that updates primary and rebases the current branch on top:
https://github.com/WickyNilliams/dotfiles/blob/c4154dd9b6980...lloeki | a day ago
I mean, while useless in terms of `git init` because the repo's already init'd, this works:
And if you have `init.defaultBranch` set up already globally for `git init` then it all just worksWickyNilliams | a day ago
In any case the main thrust was just to avoid embeddings assumptions about branch names in your scripts :)
lloeki | 12 hours ago
Fair enough!
It simply occurred to me that if your `user.defaultBranch` is set to e.g `trunk` then presumably when you `git init` you also want it to create a `trunk` branch, ergo `init.defaultBranch` would be set to the same value, ergo... irrespective of naming, could they actually be the same thing?
I can see a case for keeping them apart too though.
WickyNilliams | 10 hours ago
MathiasPius | a day ago
WickyNilliams | a day ago
huntervang | a day ago
mroche | a day ago
hiccuphippo | a day ago
devhouse | a day ago
nikeee | a day ago
https://github.com/foriequal0/git-trim
Readme also explains why it's better than a bash-oneliner in some cases.
block_dagger | a day ago
WorldMaker | a day ago
markus_zhang | a day ago
maerF0x0 | a day ago
rickknowlton | a day ago
coderpersson | a day ago
https://github.com/henrikpersson/git-trash
I use this script with a quick overview to prevent accidentally deleting something important
mrbonner | a day ago
I see that even the CIA, a federal government office, has not fully used DEI approved, inclusive language yet :-)
jen20 | a day ago
gritzko | a day ago
https://replicated.wiki/blog/partII.html
cloudfudge | a day ago
1718627440 | 13 hours ago
rtpg | 23 hours ago
Lots of people have mentioned awkward use cases where decisions have to be made. A built in command would have to confront those and it might not be easy
computerfriend | 17 hours ago
gritzko | 16 hours ago
fphilipe | a day ago
* It ensures the default branch is not deleted (main, master)
* It does not touch the current branch
* It does not touch the branch in a different worktree[2]
* It also works with non-merge repos by deleting the local branches that are gone on the remote
[1]: https://github.com/fphilipe/dotfiles/blob/ba9187d7c895e44c35...[2]: https://git-scm.com/docs/git-worktree
rubinlinux | a day ago
I have an alias I use called git default which works like this:
then it becomes This figures out the actual default from the origin.fphilipe | a day ago
jeffrallen | a day ago
I work at a company that was born and grew during the master->main transition. As a result, we have a 50/50 split of main and master.
No matter what you think about the reason for the transition, any reasonable person must admit that this was a stupid, user hostile, and needlessly complexifying change.
I am a trainer at my company. I literally teach git. And: I have no words.
Every time I decide to NOT explain to a new engineer why it's that way and say, "just learn that some are master, newer ones are main, there's no way to be sure" a little piece of me dies inside.
nicoburns | 22 hours ago
I'm personally a huge fan of the master-> main changejus5t because main is shorter to type. Might be a small win, but I checkout projects' main branches a lot.
Griffinsauce | 14 hours ago
DangitBobby | 7 hours ago
lazyasciiart | 20 hours ago
I would say any reasonable person would have to agree that a company which didn't bother to set a standard for new repos once there are multiple common options is stupid, user hostile and needlessly complexifying. And if the company does have a standard for new repos, but for some reason you don't explain that to new engineers....
1718627440 | 13 hours ago
Timwi | 12 hours ago
1718627440 | 11 hours ago
lazyasciiart | an hour ago
UqWBcuFx6NV4r | 17 hours ago
I’d consider yourself lucky that everything else is going so well that this is what’s occupying you.
tonymet | a day ago
devy | a day ago
SoftTalker | a day ago
bobjordan | a day ago
kridsdale1 | a day ago
This let them claim huge diff counts and major contributions to DEI and get promos.
tucnak | a day ago
jihadjihad | a day ago
layer8 | a day ago
Middle gray, according to modern UX designers. ;)
pmontra | a day ago
pbhjpbhj | a day ago
Blocklist makes more sense in most scenarios.
8organicbits | a day ago
reenorap | a day ago
Now, the left wing activists have turned it on its head again, and now saying that the term "black" is shameful and racist. It's bizarre how ignorant people are who say the term "blacklist" is racist.
ahhhhnoooo | 14 hours ago
Or maybe you are confusing the idea that 'using black to mean bad and white to mean good' is a problem?
Those are two different concepts.
1718627440 | 12 hours ago
I don't know of any connotation of black meaning "evil, bad, or undesirable". If anything black means "missing or vanished". Maybe that is different in your culture, but I never heard of it until now. Tons of things in everyday life are black including the most letters, signs and a lot of devices. The only thing that comes to my mind is tooth decay or pestilence, but that is hardly anything connotated with the colour per se.
8organicbits | 6 hours ago
I'd be curious to see a regional reference that shows an absorb/reflect etymology.
yokoprime | a day ago
joshuamcginnis | a day ago
imdsm | a day ago
zugi | a day ago
ffsm8 | a day ago
With git it was basically entirely driven by SJW that felt empowered by people accepting the replica rebrand
r14c | a day ago
I don't really care what the default branch is called tho so I'm willing to play along.
ear7h | a day ago
See this email for some references:
https://mail.gnome.org/archives/desktop-devel-list/2019-May/...
defen | a day ago
themafia | a day ago
Then does simply performing a search on bitkeepers documents for "slave" then automatically imply any particular terminology "came from bitkeeper?"
Did they take it from bitkeeper because they prefer antiquated chattel slavery terminology? Is there any actual documents that show this /intention/?
Or did they take it because "master" without slave is easily recognizable as described above which accurately describes how it's _actually_ implemented in git.
Further git is distributed. Bitkeeper was not.
This is just time wasting silliness.
hungryhobbit | a day ago
Yeah, it's not like 99% of the world has already switched from master to main already (without any major problems) ...
stevekemp | a day ago
These are the kinda local things that the parent was probably referring to.
tom_ | a day ago
yokoprime | a day ago
botusaurus | a day ago
are you sure this is about time/breaking and not "being told how to think"?
doetoe | a day ago
drcongo | a day ago
jldugger | a day ago
bobabob | a day ago
allthetime | a day ago
hey, gemini, how do I...
microflash | a day ago
git branch | lines | where ($it !~ '^*') | each {|br| git branch -D ($br | str trim)} | str trim
samtrack2019 | a day ago
andrewaylett | a day ago
https://gist.github.com/andrewaylett/27c6a33bd2fc8c99eada605...
But actually nowadays I use JJ and don't worry about named branches :).
Svoka | a day ago
arduanika | a day ago
tonmoy | a day ago
tpoacher | a day ago
kazinator | a day ago
Have a merge workflow which deletes the branch right there.
locallost | a day ago
andix | a day ago
All those "merged" workflows only work, if you actually merge the branches. It doesn't work with a squash merge workflow.
edit: I delegate this task to a coding agent. I'm really bad at bash commands. yolo!
renlo | a day ago
Unfortunately its name makes it hard to search for and find.
rudnevr | a day ago
The only case in which this wouldn't work is when you have a ton of necessary local branches you can't even push to remote, which is a risk and anti-pattern per se.
efficax | a day ago
9dev | a day ago
you mean the… pile of shame?
rudnevr | a day ago
1718627440 | 12 hours ago
freecodyx | a day ago
git branch -vv | grep ': gone\]' | awk '{print $1}' | xargs -n 1 git branch -D
spectaclepiece | a day ago
kccqzy | a day ago
fragmede | a day ago
so then it's `git ciaclean` and not bare `ciaclean` which imo is cleaner.
atomicUpdate | a day ago
Beyond that, this is just OP learning how `xargs` works.
nektro | 23 hours ago
tholford | 23 hours ago
https://gist.github.com/tomholford/0aa4cdb1340a9b5411ed6eaad...
chill_ai_guy | 22 hours ago
Some unhinged stuff there. Like the CIA having a project called "Fine Dining" which was basically a catalog of apps that could be put on a USB drive to hide malicious code.
A case officer picks a cover app from a list of 24: VLC, Chrome, Notepad++, 2048, Breakout. Plug in the USB. Cover app opens. Exfiltration runs silently behind it. Target walks back in and the officer can just say "oh was just playing some games on this machine"
XorNot | 22 hours ago
Like unhinged was everything to do with MKULTRA which eventually became just randomly drugging people's coffee with LSD.
1718627440 | 12 hours ago
sennalen | 22 hours ago
woodpanel | 21 hours ago
ricardobeat | 20 hours ago
The “trunk” check shows how old this is. Not nearly as useful now with rebase/squash on a remote being common, as others have mentioned.
https://github.com/ricardobeat/git-commands/blob/master/git-...
thiagowfx | 6 hours ago