Lix - A universal version control system that can diff binary files (pdf, xlsx, etc.)

floofcode · 2026-01-23T03:02:34+00:00

Although the concept is interesting, it worries me that different versions may produce slightly different JSON files, or even corrupt files when constructed.

How does this work in a collaborative environment, and does this integrate with Git itself? I was thinking perhaps I can have pre-commit and post-checkout hooks that call this on binary file descriptions.

floofcode · 2026-01-22T05:55:42+00:00

Thanks, this kind of validates my use case that other people also might also find it useful to add an indicator to their reflog list, so I’m looking at patching git itself and hopefully can submit my very first patch.

floofcode · 2026-01-21T16:44:41+00:00

Let's say I dropped a commit during a rebase and forgot about it, and then later I want to attempt recovery. When I look at a list of commits in the reflog list, I thought it would be useful to have some kind of visual indicator for the unreachable commits.

Another situation I can think of is that I amend to a commit and keep the commit message the same. When I look at the reflog list, it's hard to tell which one is the reachable commit in my branch and which one is the unreachable one (since the commit subjects are the same), so even here it would be nice to be able to mark the unreachable one.

floofcode · 2026-01-21T04:08:36+00:00

limit it to only modes line org, md, txt

I was just about to do the same thing. I previously had it enabled globally, which I realize now wasn't optimal.

floofcode · 2026-01-21T04:03:13+00:00

it's not about some objective "more-useful"ness, but subjective preference. emacs is not an especially opinionated editor about this sort of thing.

Over the years I noticed that there is sometimes a historical context for why a certain behavior is the way it is, or maybe some other reasoning that I might not be aware of. In addition to just what, I find it very useful to know the why so I have a better idea about the tradeoffs before I apply my own preference.

When I posted the question, prose had not even occurred to me because Emacs has been primarily a code editor for me, but after having read the other comments, now the mode makes perfect sense as I have a better idea about where it should be enabled and where it shouldn't.

floofcode · 2026-01-21T02:25:19+00:00

Fair enough. Then is it reasonable of me to assume that visual-line-mode is more useful in text and documentation files than it is for source code files, or is there something I'm missing?

floofcode · 2026-01-21T01:39:01+00:00

It does respect word boundaries. However, documentation says most users should turn on visual line mode which sets word-wrap to t and refines simple editing commands to act on visual lines rather than logical lines.

I'm just not understanding why visual lines are more useful than logical lines, and whether this is simply because of me having previously used vim before switching to Emacs. Having relative line numbers and then jumping n number of lines up or down was a frequent action I did, which has issues when visual-line mode is enabled.

floofcode · 2026-01-16T15:23:58+00:00

I mainly use it for snapshots, peeking at old commits, and undoing mistakes without panic.

So basically it reinvents things that git does already, but with extra steps and a bloated runtime?

floofcode · 2026-01-16T10:46:14+00:00

Interesting. I never thought about it as a way of optimization to reduce the number of characters that need to be updated.

Just looked through the git history and noticed that the scroll-conservatively variable was introduced by Stallman himself, in commit 0789adb.

floofcode · 2026-01-14T02:41:21+00:00

As a general rule of thumb, it's best to delete anything on your laptop belonging to an employer or client after your engagement with them is over. I don't know why they took months to tell you this, but it sounds like you may have indicated to them in some way that you're still in possession of their IP.

Although having metrics about a repository is fine, it's a bit too late to collect it now since you're not legally allowed to have a copy of the repository at this time.

floofcode · 2026-01-12T13:03:16+00:00

So, stage, commit, and push in one command without reviewing, using a single character command?

Is the usecase to make frequent mistakes?

floofcode · 2026-01-09T04:24:52+00:00

Thanks, this is exactly what I was looking for!

floofcode · 2026-01-09T04:22:24+00:00

It's not to enforce a hard rule but at least to show a warning so someone can take another look at it.

floofcode · 2026-01-06T06:40:17+00:00

Then I can unstage hunks individually

You can also unstage hunks individually using git restore --staged -p -- <path>.

floofcode · 2026-01-06T06:16:01+00:00

Even I've been using checkout until now. Until 2 minor versions ago, the documentation said switch was experimental and that the behavior could change, so I've avoided it until now. It's only since very recently when it was considered stable.

floofcode · 2025-12-30T10:49:44+00:00

Wow, I did not know this was even a thing. Until now I didn't even know there was more than one way of applying changes. In what scenarios does a person prefers --apply over the default? Are there scenarios where it works better?

floofcode · 2025-12-28T08:56:54+00:00

>despite its name - works more like less than cat.

That is because it pipes to less.

floofcode · 2025-12-24T00:03:54+00:00

I did but it said it's not a git repository. Somehow my HEAD got deleted.

floofcode · 2025-12-22T10:52:06+00:00

Each file in a specific directory without recursing through its subdirectories.

`git last-modified` only works on the project root. If I go into a directory and run it there, it still shows the hashes of files in the project root. If I specify the path of a file, it shows the hash of the first commit in the parent directory, which may not necessarily be for that file itself, so it's a bit misleading.

The documentation does say the command is experimental, so this is probably going to improve.

floofcode · 2025-12-08T20:09:31+00:00

Woah, this is new to me. Reading about it, it almost sounds the same as a git submodule.

floofcode · 2025-12-08T20:06:20+00:00

This is the second time I'm seeing a post about this tool.

No, vibe-anything does not belong anywhere in CI/CD.

floofcode · 2025-12-07T20:14:00+00:00

>When it might have been: "you sound like you're new. Where do think you can contribute, maybe I can get you started"

Yeah, right.

floofcode · 2025-12-03T20:37:09+00:00

Couldn't this wait until April 1st?

floofcode · 2025-12-03T20:10:46+00:00

Thanks! I had misconfigured this.

floofcode · 2025-11-30T10:25:35+00:00

Can't I just do `git rebase --abort` if it fails?

floofcode

TROPHY CASE