avgcorrection

I’ll try to do better in the next life.

> But go ahead and use the FFI and things aren't so rosy. Usually the GC can cooperate with allocated memory from the other side of the FFI, but this requires care and attention to detail, or you get memory bugs, and just like that, you're manually managing memory in a garbage collected language, and you can segfault on a use-after-free just like a Real Programmer.

Now you’ve stepped beyond the walled gardens of the managed memory. How is that an abstraction leak?

> It's also quite plausible to write a program in a GC language which leaks memory, by accidentally retaining a reference to something which you thought you'd deleted the last reference to.

That the user just thought they had gotten rid of? If the memory is technically reachable then that doesn’t sound like its fault. I’m reminded of the recent Rust Vec thread on how the so-called space leak of reusing allocated memory lead to unreasonable memory consumption. But to my recollection that wasn’t a leak in the sense of unreachable-but-not-freed. I do agree however (with those that made this point) that the Vec behavior was too clever. Which goes to show that Vec should probably just stick to the front-page abstraction advertised: will amortize allocations, can shrink to fit if you tell it to, nothing much more fancy beyond that.

(The memory leak topic seems very fuzzy in general.)

What was difficult about what I wrote?

> Back to TCP. Earlier for the sake of simplicity I told a little fib, and some of you have steam coming out of your ears by now because this fib is driving you crazy. I said that TCP guarantees that your message will arrive. It doesn’t, actually. If your pet snake has chewed through the network cable leading to your computer, and no IP packets can get through, then TCP can’t do anything about it and your message doesn’t arrive.

The argument is disqualified at this point. The whole world is a leaky abstraction because <freak meteor hit could happen>. At this point your concept is all-encompassing and in turn useless.

There are assumptions: this computation will finish eventually [assuming that no one unplugs the computer itself]. This does not make things leaky.

There are leaky abstractions I guess but not all are. A garbage collector that can cause memory errors would be leaky. I don’t know anything about garbage colletors but in my experience they don’t.

Then someone says that a garbage collector is leaky because of performance concerns (throughput or latency). That’s not a leak: that’s part of the abstracting away part—some concerns are abstracted away. To abstract away means to make it something that you can’t fudge or change. To say that “this is implementation-defined”. An abstract list is an abstraction in the sense that it has some behavior. And also in the sense that it doesn’t say how those behaviors are implemented. That’s both a freedom and a lurking problem (sometimes). Big reallocation because of amortized push? Well you abstracted that away so can you complain about it? Maybe your next step is to move beyond the abstraction and into the more concrete.

What are abstractions without something to abstract away? They are impossible. You have to have the freedom to leave some things blank.

So what Spolsky is effectively saying is that abstractions are abstractions. That looks more like a rhetorical device than a new argument. (Taxes are theft?)

EDIT: Flagged for an opinion? Very well.

Ok. That could work if you found a group of people who are interested in such an all-in-one package. Gitlab is apparently working on a sort of cross-forge protocol (probably motivated by connecting Gitlab instances) and it seems that some Gitlab employees are working full time on the Git project. So those are candidates. You probably need a group which both have recognition within the project and are active enough to drive such a project forward without it fizzling out.

Without such a group you might just send a few emails to mailing list, get shrugs about how that plan “looks good” with little real interest, and then have to discuss this big plan in every future patch series that incrementally builds such a thing into Git itself. Mostly why such code should be incorporated and how it will pay off when it’s all ready.

The Git tool itself—and the project by extension—is per now very unopinioated about whole-project solutions like this. The workflow that they themselves use is very loosely coupled and pretty much needs bespoke scripting by individual contributors, which I guess is telling in itself.

Amendment: I just found out that I do have at least one use for git-stash, which is when I am stuck in the middle of a rebase somewhere and made an edit intended for another point (commit).

And Fossil is an entirely different VCS.

What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation? (Then maybe someone can complain about design-by-committee.)

My comment was totally unclear. By primitive I mean that it scales from very primitive operations (just snapshot) to supporting high-level workflows (refactoring, testing, verifying).

And by primitive I mean that I want to be able to commit whenever I feel like I want a snapshot. For any reason. Not hindered by concepts like does-it-build. That’s the low level. Then at the higher level are things like “public history” and “tested history”. That’s facilitated by the low/mid-level history rewriting tools.

Some people I know use Intellij’s “shelve” feature or whatever it is called. Interestingly it does provide some features that Git does not seem to have—and overlaps with GitButler—but it’s own bespoke thing, not integrated with Git.

And using these extra concepts on top of (or under?) Git doesn’t make sense for my workflow. Because the VCS is already there. So I don’t need to think about if I’m ready-to-commit—just make a WIP or a TEST commit, maybe discard later or maybe rewrite them.

For me, Git covers everything from snapshotting some private notes I have on the work that I’m currently doing to making a nice:

> useful commit [history], both for any reviewers at the time and any code spelunkers 10 years into the future.

It provides that whole range.

I think that you (like me) prefer to use commits in places where many others prefer to stash. Personally I think the stash command is too primitive to bother with for all things except maybe an push+pop that happens within half a minute. Anything more and I risk forgetting about it. A WIP commit however is just there, on the branch, for me to deal with however I want later.

I don’t want to fiddle with dropping the stash one too many times, forgetting what they were about and so on. Merge conflicts because I didn’t pop before resuming..

It’s just a mostly useless additional “thing”.

You don’t have to interpret it as you-always-do-this. Just sometimes you want a worktree (or clone): maybe the bug fix needs to be applied to an old, old release which would invalidate all the indexes in your project. So then you can make a worktree so that your main worktree is left in peace.

But is it overkill for some fast translation fixes? Yeah, probably:)

“Not in a position to commit” in Git makes as much sense as “not in a position to save the file” (in your editor) in 2024. Git is in a sense a primitive tool: only about snapshotting, not about high-falutin things like “passes the tests”, “is okay with Bob”, and so on. It’s just about tracking state.

(Again this is what git-reset(1) and friends are for)

This is the way. Just commit. You can undo it later or whatever, but at least it’s there.

Just one concept instead of (1) commits (2) stash (3) oh these changes, eh, I don’t know what to do with them... let’s think about it after lunch.

> The thing that annoys me about worktrees is that you can't have two checked out to the same commit at the same time

Checking out the same commit is fine. You just can’t checkout the same branch.

This is not a problem for me because I either use detached head (if say I’m going to build from some commit) or restrict branches to certain worktrees naturally (if I am backporting to `old-version` on a worktree then... it’s not like that backport branch is ever going to be relevant in my main worktree where I do most of my work).