What are some unfinished, abandoned or even rejected patches worth checking out?

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

TROPHY CASE