site banner
PaperclipPerfector  3d ago (text post)   1791 thread views

Small-Scale Question Sunday for November 23, 2025

Do you have a dumb question that you're kind of embarrassed to ask in the main thread? Is there something you're just not sure about?

This is your opportunity to ask questions. No question too simple or too silly.

Culture war topics are accepted, and proposals for a better intro post are appreciated.

2
Top Bottom Old Controversial Comments
Jump in the discussion.

No email address required.

Are people here familiar with git frontends?

Having again lost a day's work to git deciding to delete files I hadn't committed yet (nor will I ever commit to the master), I'm now looking for a git frontend that doesn't completely suck balls. Is there anything that fits the following tenets:

  1. My local files are sacred. Under no circumstances can they be deleted without some way to undo it. No exceptions. If the files in the repo and my working copy differ, show it to me so I can choose what to do on a per-file / directory basis.
  2. The repo has only a single origin. I don't care if Linus needs twenty thousand different repos to pull and push things from. I use one. The tool shall treat every branch as always having that as origin.
  3. A submodule should only mean the short text file that contains the SHA hash. The contents of submodule directories should be completely ignored when pulling, merging, committing or pushing. Yes, I know the repo's submodule refers to a different set of files than the ones in my working copy. That is intentional.
  4. I don't want to ever have to see or care about staged files. My files are either being worked on or have been committed. There is no such thing as a staged file.
  5. No operation should leave things halfway, something staged or any ><!¤#"¤#% characters in files. It either completes succesfully or leaves the working copy as it was before. Not some quantum Schrödinger's halfway state.

It gets really laborous having to have the actual working copy, the one git wants to see and the authorative origin/master and manually trying to manage them without git completely fucking up my working copy just because a branch pointer was changed somewhere.

I don't want to ever have to see or care about staged files. My files are either being worked on or have been committed. There is no such thing as a staged file.

Maybe take a look at jujutsu: https://github.com/jj-vcs/jj

It uses git as a back-end so it's completely compatible with git, but it follows the idea that you always have a commit in the works:

Working-copy-as-a-commit: Changes to files are recorded automatically as normal commits, and amended on every subsequent change. This "snapshot" design simplifies the user-facing data model (commits are the only visible object), simplifies internal algorithms, and completely subsumes features like Git's stashes or the index/staging-area.

It doesn't really address your specific concerns, but I prefer lazygit over pretty much any other way of interacting with git. A coworker keeps pushing me to switch to jujutsu but I'm too old to switch vcs conventions.

  1. IIRC the only high-level git commands that will remove untracked changes are clean, checkout, reset, and restore. You should be able to avoid this by not using them: every usage of checkout can be replaced by another command, and the others are specifically for discarding changes.
  2. Set push.autoSetupRemote to true. This will automatically create remote tracking branches on push. If you run push, pull, or fetch with no arguments they will automatically use your single origin.
  3. Use status --ignore-submodules=dirty. There's also the config option submodule.<name>.ignore=dirty, but that needs to be set for each submodule. You can make that status command an alias if you don't want to type it out every time.
  4. For existing files, you can do commit -- file1 file2 .... You still need to explicitly stage any newly created files, and it won't work during merges.
  5. In your git attributes file, put * merge=binary. If both branches have changes to a file, git will not modify the file, but will print an error saying there was a conflict and put it in the "unmerged paths" section of the status.

I have enjoyed using Sublime Merge. I would say that

Having again lost a day's work to git deciding to delete files I hadn't committed yet (nor will I ever commit to the master)

sounds like the best solution would be using .gitignore more. We're all hypocrites but IMO all your files should be either committed to git, or ignored.

I'm now looking for a git frontend that doesn't completely suck balls

I've been working with git for a long time, probably over a decade. Never seen a frontend that would replace CLI for me. And in fact I don't think there exists any frontend that would deliver on what you're asking for. It's just not how git is meant to work. You have the right to want to do different things, but I don't think any git frontends would deliver them to you, because they are mostly paving the walkways, not trying to make git look like not git.

For (1), git is usually pretty conservative about touching your files, unless you tell it not to. But yes, each command has a "force" flag which will completely ruin your day if you force something that wipes your files. I feel like asking for a tool that can't do that is like asking for a safe knife - the only safe one is a useless one, as it won't cut.

For (2) if you have one remote, you should be fine, if you have multiple ones, there some setup is requires, probably some custom scripting and hooks would help. Unfortunately, that part of git UI is not excellent - I have occasionally pushed and pulled from a wrong remote and it's confusing as hell.

For (3), by default that's how git treats it, if you're in the main repo, the submodule diffs would only be shown as "modified" without any details. If you need more stuff happening there, probably hooks could help.

For (4) that's not really how git is supposed to work, but if you never use "add" command and only use "commit" then it should be like that. Of course, some more advanced command may have implied "add" so it again can get confusing.

For (5) unfortunately I don't think it's possible, at least not with how git models the universe - it keeps the state in files themselves during merge process, so if you are in the middle of this process, that's what you'd get and I don't think any frontend can change that, unless it basically reimplements a lot of it in a different way.

I am not a git GUI guy, I've always used IDEs and the CLI. I've heard, however, that many high-caliber devs I know have historically paid for Kraken.

Some of the other things you demand here can and should be set up with pre-command hooks (outlawing other repos). Some can be accomplished by writing your own commands or overwriting the stock ones. I've written 3 for myself:

  • checkpush - single command to create a new branch on the remote and commit to it
  • fullprune - removes local branches that were deleted in the remote after squash merges
  • refresh - gets the latest commits from master and merges them into your current branch. If you squash, it's very reliable.

Making committing a single step (no staging) will be very simple this way.

I'm not a high-caliber dev, but I've used and will recommend gitkraken, especially for very large teams or very distributed projects; it's one of the few that handles heavily forked projects and related PRs well. That said, I don't know that that it does much to solve these specific issues.

What is this place?

This website is a place for people who want to move past shady thinking and test their ideas in a court of people who don't all share the same biases. Our goal is to optimize for light, not heat; this is a group effort, and all commentators are asked to do their part.

The weekly Culture War threads host the most controversial topics and are the most visible aspect of The Motte. However, many other topics are appropriate here. We encourage people to post anything related to science, politics, or philosophy; if in doubt, post!

Check out The Vault for an archive of old quality posts. You are encouraged to crosspost these elsewhere.


Why are you called The Motte?

A motte is a stone keep on a raised earthwork common in early medieval fortifications. More pertinently, it's an element in a rhetorical move called a "Motte-and-Bailey", originally identified by philosopher Nicholas Shackel. It describes the tendency in discourse for people to move from a controversial but high value claim to a defensible but less exciting one upon any resistance to the former. He likens this to the medieval fortification, where a desirable land (the bailey) is abandoned when in danger for the more easily defended motte. In Shackel's words, "The Motte represents the defensible but undesired propositions to which one retreats when hard pressed."

On The Motte, always attempt to remain inside your defensible territory, even if you are not being pressed.


New post guidelines

If you're posting something that isn't related to the culture war, we encourage you to post a thread for it. A submission statement is highly appreciated, but isn't necessary for text posts or links to largely-text posts such as blogs or news articles; if we're unsure of the value of your post, we might remove it until you add a submission statement. A submission statement is required for non-text sources (videos, podcasts, images).

Culture war posts go in the culture war thread; all links must either include a submission statement or significant commentary. Bare links without those will be removed.

If in doubt, please post it!


Rules


Recommended Posts And Communities

Recommended Realtime Chats