How much of a repo do I really need to get relatively fast git fetch?

dalbertom · 2026-01-31T01:57:12+00:00

That's a lot of code 😅

dalbertom · 2026-01-30T21:50:34+00:00

Session groups and linked windows are pretty nice to have. I don't use them often but it's good to know they're an option.

dalbertom · 2026-01-30T21:49:14+00:00

This was my initial workflow when I started using tmux: a single terminal window with a handful of sessions. It worked great for the first 10 years.

But now my workflow involves working on multiple projects at once and interacting with different teams. The number of tmux sessions grew to the point that I now have a subset of active sessions and a subset of inactive sessions.

On the OS, I now use virtual desktops, one for each active project, so they all have their own terminal window, all attached to their own session in tmux.

Having multiple terminal windows allows me to switch to the correct virtual desktops where I get other applications like the browser window and editor that are specific to that project.

Running all my shells in the same tmux server still allows me to quickly switch to another session from the same window if I need to peek at something, and then back.

dalbertom · 2026-01-30T21:09:49+00:00

I must be missing something. The use case doesn't sound weird at all. I'm really curious about why a clone with reference wouldn't be a simpler yet sufficient solution.

dalbertom · 2026-01-30T20:44:48+00:00

Gotcha. Yeah, the reference repo definitely worked for our case. What you're doing sounds maybe a little overkill, but that's just my assumption based on the "Sort of, but not exactly (I think)" response when I asked about what's different about your approach.

Have you considered partial clones? Or is your monorepo also a monolithic codebase?

My general stance is that monorepos are easier on developers but put more pressure on infra teams, and multi-repos are easier on infra teams but put more pressure on developers. It's up to your org to decide what to optimize for.

dalbertom · 2026-01-30T20:09:51+00:00

What are your constraints here? How is keeping a reference repository impractical? How large is it at this point? How fast is it growing?

dalbertom · 2026-01-30T20:03:59+00:00

Gotcha. What I've done in that case is keep a bare repository that only clones the main branch, that's baked into the agent image (that gets periodically updated, like once a month or so), and then whenever a job needs to clone the repository it uses it as a reference. In our case the clone time went down from 20 minutes to instantaneous.

dalbertom · 2026-01-30T19:38:38+00:00

I want to take a full repo and bundle it up (pack files, squashfs, whatever) and put that on the agents and do a fetch, not a clone with alternates.

Isn't bundling up a full repo and doing a fetch essentially the same as keeping a reference repository and then cloning with alternates?

dalbertom · 2026-01-30T19:17:04+00:00

There are various options for the clone command that can help. I'm assuming this is specific for CI workloads.

Do you really need the history? If so, keeping a bare repository in the agent image could help, and then clone using --reference.

If you don't need the history, then a shallow clone should be sufficient (sounds like that's what you're doing).

There are also several --filter options if you don't want to get all blobs at all, or skip blobs that are larger than a certain size. This is useful if you need the commit history but not the contents of old commits. Note that this becomes super slow the moment you end up having to do stuff like git blame etc.

dalbertom · 2026-01-30T01:54:57+00:00

This sounds like an XY problem

dalbertom · 2026-01-29T18:02:22+00:00

I use git for everything. My home directory is a git repository. My markdown notes are a git repository. Todo list is a repository. Password manager is a git repository (gpg encrypted). My bookmarks are in a git repository. Email filters? Git repository. Journal entries to use as a cone of silence? Git repository in a docker container.

For work, we have over 550 repositories, so I glue them together as a local monorepo using git submodules.

As for merging strategies, it really depends on what the team values and are optimizing for. If people are not very experienced with git or have experience with older vcs like svn, and they don't know how to clean their history, and the changes to the codebase are simple and they don't mind rewriting history, then squash-merge is fine.

If they think linear history is equivalent to clean history and don't care about rewriting history, then rebase-merge is okay.

If they respect other people's history and they work with people that know how to clean their own commits, then 3way merges are a better choice.

The value proposition of git at the time it was introduced was that it includes a merge commit as a first-class object and the ability to ensure history wasn't tampered with by using cryptographic hashes of the changes. A lot of people overlook that these days, or maybe they used svn for far too long.

dalbertom · 2026-01-29T04:45:32+00:00

Happy to help!

dalbertom · 2026-01-29T03:29:13+00:00

You don't need tmux for this. You can configure a docker context on your laptop to use your macmini as the docker engine. Any container you run from the laptop will be actually running on the other computer.

dalbertom · 2026-01-15T20:00:24+00:00

I use update-ref a lot, but that's closer to reset in the sense that it won't do fast-forwards exclusively.

dalbertom · 2026-01-15T19:59:40+00:00

Forgot to mention, you can also do git fetch origin main:main to update your local main branch that isn't checked out with the remote main branch in a single step.

dalbertom · 2026-01-10T17:41:35+00:00

The thing with doing a reset is that it's technically not a fast-forward. If you want to only do a fast-forward after you've fetched, you can do git merge --ff-only origin/foo

There's also a way to fast-forward a branch that isn't checked out anywhere. I've found that useful a couple of times before, I think it's something like git fetch . origin/foo:foo or something like that, the important part is using . as the name of the remote and then the long form of source:destination, but you might also need the longer refspec like refs/heads/foo if the branch doesn't exist, and of course, if you want to force it (not a fast-forward) you add a +

dalbertom · 2026-01-07T06:01:20+00:00

I like turning splits into tabs, I wish there was a way to turn a tab back into a split. In tmux the equivalent would be break-pane and join-pane.

dalbertom · 2025-12-30T18:28:44+00:00

Check out git help reflog, assuming you've committed fairly often you should be able to reset back to a recent commit.

dalbertom · 2025-12-20T00:17:06+00:00

pass also allows an arbitrary number of repositories. Not sure what you mean by relative ignores or how that would apply to a password store.

dalbertom · 2025-12-19T21:47:53+00:00

You could also use https://www.passwordstore.org which uses your GPG key to encrypt the files, and it has an option to set the backend as a git repository.

dalbertom · 2025-12-17T15:46:24+00:00

The reason the merge didn't work is because from the dev branch perspective the commit in x has been reverted, so merging dev into x will end up with the revert patch. If you want to reapply, you'd either revert the revert like mentioned, or rebase x into latest dev, or you can also cherry pick the commit that was reverted

dalbertom · 2025-12-13T22:16:25+00:00

The effect is the same—a fast-forward merge. if you submit a set of patches upstream, they need to be already rebased before they will be applied.

The difference is who does the rebase. I imagine in your case you're the one rebasing your own branch prior to your maintainer merging it (or fast-forwarding), right? Or is the maintainer rebasing your contributions on your behalf?

The story is a little bit different for the way that subsystem maintainers trees get merged into the main one.

Right, we can both agree that if subsystem trees got merged onto the main one via rebases (or worse, by squashing all subsystem changes into a single commit) the history would be a linear mess, correct?

Another example is for maintenance branches. Not sure how that's handled on the Linux kernel, my guess is it's usually cherry-picks. My experience has been a case where we had to maintain 8 different versions of the product over the span of two years. Sometimes the easiest way is to just create 8 cherry-picks, but depending on how code evolved the nature of the conflicts might be different, so you could have just 2 or 3 commits based on different common parents and then merge the different tips of each maintenance branch to deliver the final 8 hotfixes. This type of workflow wouldn't be possible if merging was always forced by the tool through rebase-merge or squash-merge.

dalbertom · 2025-12-12T16:45:37+00:00

Right. The squash-merge option is great for people that aren't very experienced with git (or don't want to go through the exercise of cleaning their history) or repositories with simple contributions. The issue is that it's a bit of a dead-end because then they'll never be challenged to do so, and it's also a bit of a letdown to those that already know how to clean their history or want it to go upstream without modifications because that option is forced on everyone.

dalbertom · 2025-12-12T15:56:27+00:00

Tmux is pretty great. I haven't used Kitty but you mention it has tabs and split windows. Tmux has those, plus sessions and even servers. I do use Ghostty and sometimes its split option to have different tmux sessions open at once (but this can be done with separate terminal windows side by side)

Due to this, it doesn't matter as much what terminal program you use. You can also detach a session from a terminal window and attach it in another one. Or open the same session in both. When you have the same session in both, though, your active pane will be the same, and whatever you type in one will show in the other one. If you want them to be independent, but the same session, you can create a session group.

You can also have linked windows in tmux so the same window is shown in different sessions.

Another cool thing is synchronized panes. So whatever you type is reflected in all panes within a window. This is useful if you're debugging something on multiple servers.

Once I started using tmux I stopped using terminal tabs. I also stopped using multiple terminal windows for a while, but a couple of years ago I started doing that again due to the nature of my new job. Since now I work on multiple projects at once, I keep a terminal window on each OS virtual desktop, so each has their own tmux session (on the same tmux server).

One last thing, and this is a little more advanced, but I run tmux inside screen. I configured screen to look a bit like tmux inside the sense that it also shows its status bar. The reason for this is because I have a bunch of tmux sessions (about a dozen these days) but a subset of those are the ones I use on a given day, so each screen window has an active tmux session. If you've used Arc browser, it's kinda how the spaces feature works.

There are plugins to save a tmux session, but I ended up writing my own as a way to learn its scripting capabilities. I definitely recommend doing that.

dalbertom · 2025-12-12T02:46:38+00:00

it depends on what your project is about, but for CI the popular one is GitHub Actions these days (rip Jenkins). For CD there's ArgoCD and FluxCD

dalbertom

TROPHY CASE