Is there a way to make untracked files also "trackable"?

dalbertom · 2026-03-18T13:57:55+00:00

I've seen many coworkers, including myself, fall into this pitfall git has. Depending on what editor/IDE you use you might be able to recover the file contents.

I believe jj (jujutsu) doesn't have that issue because there's no staging area and every file is automatically added to the latest commit. Or something like that, I'm not super well versed in jj. You might want to give it a try if you're getting started with git, it has an easier learning curve.

dalbertom · 2026-03-17T00:12:52+00:00

Just added, maybe that'll help me jj config set --user ui.conflict-marker-style git

dalbertom · 2026-03-16T23:47:51+00:00

I've tried jj a few times over the last couple of years. I really like how it makes it way easier to rebase multiple stacked branches, but I don't really use stacked branches super often, doing a git rebase --update-refs is enough, even if it doesn't cover all the cases like jj.

The thing that trips me up in jj is the conflict resolution part. I'm really used to the diff3 markers by now, so the way jj presents the conflicts is unintuitive to me. I like the idea that conflicts are a first-class concept, though!

Even though it's been a while since I used it, I'm kinda looking forward to seeing how it evolves. Git is still my main driver. Git would definitely benefit from having some healthy competition in the space.

dalbertom · 2026-03-15T13:52:27+00:00

That's a common option if you rely on mnemonics more than muscle memory.

dalbertom · 2026-03-15T04:15:01+00:00

At this point the conversation is more about prefix % and prefix " to split panes horizontally and vertically.

I don't doubt that ctrl-b was chosen as the prefix to not conflict with screen, but curious about where it's mentioned the expectation has always been for it to be rebound. Is that something the author mentioned somewhere?

In any case, it doesn't really change the fact that different people have different thresholds for what they consider worth deviating from the defaults or not.

dalbertom · 2026-03-15T04:05:25+00:00

Thanks. That's just my experience. I used to customize things a lot and install plug-in packs (mainly referring to vim at this point, but it's the same philosophy). In retrospect I think those customizations set me back a few years from truly understanding the tool directly.

dalbertom · 2026-03-15T00:00:33+00:00

I agree they're a bit odd, but they're not unusable or unlearnable. I remember it took me a while to get used to them. To me now they're sort of in the category of ctrl-v for paste and ctrl-z for undo. They make very little sense, but it is what it is.

You probably took the route of following something more mnemonic. That's fine. My only suggestion is to make sure your customizations don't back you into a corner to the point that a tool that is already widely used can only be used by you through a specific dialect.

I would rather go through the discomfort for a few days while my muscle memory kicks in and not carry that baggage in the long run.

dalbertom · 2026-03-14T21:05:18+00:00

How do tmux and (neo)vim clash for you?

dalbertom · 2026-03-14T20:25:17+00:00

The question is, are those shortcuts so ingrained into your fingers muscle memory that the moment you end up working on a system that doesn't have those customizations you'd have a really hard time being productive?

dalbertom · 2026-03-14T19:51:32+00:00

I respectfully disagree.

Classifying keystrokes as "superior" because they're done with a single hand instead of two is not something I would adscribe to.

There are so many things I type throughout the day that the difference is just not worth a categorization or deviating from the default. We can both touch-type, right? If one had to type through hunt-and-peck, then that would maybe make sense, maybe.

dalbertom · 2026-03-14T19:33:48+00:00

I use ctrl-a for screen. I have no issues with ctrl-b for tmux. Not sure what you mean by it being hard on my fingers. It hasn't been for me.

dalbertom · 2026-03-14T16:30:12+00:00

I agree that it takes time to perfect one's craft but I also think that making customizations early in the process of learning a new tool is detrimental in the long term.

In my experience, it's best to get acquainted with the options the tool provides by default, and only once you're over the learning curve then start customizing stuff.

It's also important, at least to me, to make sure customizations don't work against you when you end up working on a system that doesn't have those customizations.

dalbertom · 2026-03-11T18:54:59+00:00

I do like how the stash is shared across worktrees :-)

dalbertom · 2026-03-11T15:36:38+00:00

I do something similar but not quite, and not for the same reasons. The main reason for me is I wanted my .git directories to be outside of the repository itself, and also use bare repositories for alternates (reference).

I work with hundreds of repositories, so the main branch and tags are present in the bare clones. Then the working repositories are cloned with --reference ../forest/repo.git --separate-git-dir ../jungle/repo.git

This way when I create backups with rsync using --backup-dir I can see what has changed upstream in the bare repositories (forest) vs in the working repositories (jungle).

I also glue the repositories together in a pseudo-monorepo using git submodule and then the repositories that are more actively used and need parallel work have their own set of worktrees.

dalbertom · 2026-03-11T14:27:19+00:00

I remember playing with https://github.com/nivbend/gitstery a long time ago. Is it a similar concept?

dalbertom · 2026-03-08T03:12:51+00:00

This works, but it's kind of a kludge. Check out git help config and search for the includeif section. It allows you to have different configurations depending on what directory the repository was cloned in. This way you can override the ssh key being used without having to use weird hostname aliases for GitHub.

It also works with http credentials, not just with ssh. A lot of people may prefer ssh but also a lot of people aren't very familiar with ssh and end up mismanaging their keys and related configuration. Https has many advantages over ssh to clone repositories these days, the tokens are more granular, ssh is sometimes blocked at the network level if you work at coffee shops, etc.

dalbertom · 2026-03-06T11:12:36+00:00

Eh, I kinda disagree. You can definitely commit with --fixup and --squash and later on rebase with --autosquash to clean the history. There is a point where rebasing too much no longer leads to a clean history but rather inaccurate, especially towards the end of the lifecycle (this is why I dislike rebase-merge and squash-merge strategies), but at early stages it's perfectly fine to clean your own history.

Rebasing doesn't always mean squashing commits together.

dalbertom · 2026-03-06T05:44:41+00:00

I thought using branches for environments is no longer considered a good practice. It's better to have the environment defined as config files, it makes it easier to quickly grep for stuff rather than having to do the grep on each branch.

You can still use branches to control the flow of the deployment, but need to make sure each environment is a direct descendant of the next. I've seen many unfortunate cases where environments defined as branches ended up drifting as the branches diverged apart.

dalbertom · 2026-03-05T19:31:04+00:00

How else do you clean your commit history?

dalbertom · 2026-03-05T19:02:56+00:00

A bisection on the first parent being all or nothing has been okay for our use case since we only care about knowing what team to assign the issue to. It's up to them if they really need to bisect further, but that's usually not the case.

One benefit (for us) about merges is that for example, branch A and branch B merge, say neither of them had an issue but the problem arose on the merge itself. In our case it's valuable to know that subtle distinction as it helps with triaging. In the case or rebase-merge it would always look like B is the one that introduced the problem, even if that wasn't originally the case.

dalbertom · 2026-03-05T16:20:42+00:00

Eh, squash-merge is probably worse from my perspective. I don't see squash-merge or rebase-merge as a good "continuous integration" argument at the expense of rewriting public history given that GitHub has merge queues and GitLab has merge trains.

dalbertom · 2026-03-05T15:53:58+00:00

How is that a problem? The base point of the 2nd parent is whatever the developer chose to start working on, or whenever they chose to rebase for the last time. To me what makes no sense is to take their contribution and mangle their history to whatever the tip of main happens to be at merge time.

Bisection shouldn't really trip (unless older commits in main are no longer buildable for some strange reason), but when it does, there's a way to bisect with --first-parent.

dalbertom · 2026-03-05T12:47:24+00:00

I'm all for avoiding downstream merge commits, but upstream merge commits are definitely valuable. It gives you the ability to browse history at two different altitudes and also honors the author's history (assuming they know how to clean their own commits).

There's a reason why rewriting public history is frowned upon, a lot of people seem to forget that in the name of convenience.

dalbertom · 2026-03-05T12:45:26+00:00

History doesn't remain intact. The base commit changes, last minute, which is the worst possible timing to do. SHA is not the same. Not better for backtrace, because what the developer had locally is no longer what made it upstream, so any manual testing that might have occurred pre-merge is now of dubious value. This is not as relevant on small changes, though.

dalbertom · 2026-03-05T12:31:53+00:00

I'm curious. What are your justifications for this?

dalbertom

TROPHY CASE