Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Who needs Git when you have 1M context windows?

alexmolas.com

Post reply on HN
Print view View original

51–60 of 199 posts

Re: Who needs Git when you have 1M context windows?

#51

Post by monsieurbanana »

SketchySeaBeast wrote: post #49
globular-toast wrote: post #47

Earlier quoted context omitted.

Indiscriminate squashing sucks. Atomic commits are great if you want the git history to actually represent a logical changelog for a project, as opposed to a pointless literal keylog of what changes each developer made and when. It will help you if you need to bisect a regression later. It sucks if you bisect and find the change happened in some enormous incohesive commit. Squashing should be done carefully to reform…

> It sucks if you bisect and find the change happened in some enormous incohesive commit. But why are any PRs like this? Each PR should represent an atomic action against the codebase - implementing feature 1234, fixing bug 4567. The project's changelog should only be updated at the end of each PR. The fact that I went down the wrong path three times doesn't need to be documented.

> Each PR should represent an atomic action against the codebase

We can bikeshed about this for days. Not every feature can be made in an atomic way.

Re: Who needs Git when you have 1M context windows?

#52

Post by withinboredom »

monsieurbanana wrote: post #51
SketchySeaBeast wrote: post #49

Earlier quoted context omitted.

> It sucks if you bisect and find the change happened in some enormous incohesive commit. But why are any PRs like this? Each PR should represent an atomic action against the codebase - implementing feature 1234, fixing bug 4567. The project's changelog should only be updated at the end of each PR. The fact that I went down the wrong path three times doesn't need to be documented.

> Each PR should represent an atomic action against the codebase We can bikeshed about this for days. Not every feature can be made in an atomic way.

This simply isn’t true unless you have to put everything in one commit?

To be honest, I usually get this with people who have never realized that you can merge dead code (code that is never called). You can basically merge an entire feature this way, with the last PR “turning it on” or adding a feature flag — optionally removing the old code at this point as well.

Re: Who needs Git when you have 1M context windows?

#54

Post by bayindirh »

cranium wrote: post #38
dotancohen wrote: post #4

Don't take this as career advice! This is an amusing anecdote. But the only lesson to be learned is to commit early, commit often.

Commit even as a WIP before cleaning up! I don't really like polluting the commit history like that but with some interactive rebase it can be as if the WIP version never existed. (Side ask to people using Jujutsu: isn't it a use case where jujutsu shines?)

I always commit when wrapping up the day. I add [WIP] in the subject, and add "NOTE: This commit doesn't build" if it's in a very half-baked state.

Re: Who needs Git when you have 1M context windows?

#55

Post by SketchySeaBeast »

monsieurbanana wrote: post #51
SketchySeaBeast wrote: post #49

Earlier quoted context omitted.

> It sucks if you bisect and find the change happened in some enormous incohesive commit. But why are any PRs like this? Each PR should represent an atomic action against the codebase - implementing feature 1234, fixing bug 4567. The project's changelog should only be updated at the end of each PR. The fact that I went down the wrong path three times doesn't need to be documented.

> Each PR should represent an atomic action against the codebase We can bikeshed about this for days. Not every feature can be made in an atomic way.

That's true, some are big and messy, or the change has to be created across a couple of PRs, but I don't think that the answer to "some PRs are messy" is "let's include all the mess". I don't think the job is made easier by having to dig through a half dozen messy commits to find where the bug is as opposed to one or two large ones.

Re: Who needs Git when you have 1M context windows?

#56

Post by BryantD »

dotancohen wrote: post #4

Don't take this as career advice! This is an amusing anecdote. But the only lesson to be learned is to commit early, commit often.

I think maybe one other lesson, although I certainly agree with yours, and with the other commenters who talk about the unreliability of this particular method? This feels like an argument for using an editor that autosaves history. "Disk is cheap," as they say -- so what if your undo buffer for any given file goes back seven days, or a month? With a good interface to browse through the history?

I'm sure there's an emacs module for this.

Re: Who needs Git when you have 1M context windows?

#57

Post by SketchySeaBeast »

bayindirh wrote: post #54
cranium wrote: post #38

Earlier quoted context omitted.

Commit even as a WIP before cleaning up! I don't really like polluting the commit history like that but with some interactive rebase it can be as if the WIP version never existed. (Side ask to people using Jujutsu: isn't it a use case where jujutsu shines?)

I always commit when wrapping up the day. I add [WIP] in the subject, and add "NOTE: This commit doesn't build" if it's in a very half-baked state.

I do a bunch of context switching, and I commit every time I switch as stashing would be miserable. I never expect those WIP commits to reviewed and it'd be madness to try.

Re: Who needs Git when you have 1M context windows?

#58

Post by SketchySeaBeast »

onionisafruit wrote: post #27
f1shy wrote: post #17

Earlier quoted context omitted.

And in general maybe have a better working methodic, or however you name it. Sounds like messing around to me.

I like to mess around. Some of my best work comes out of messing around. The trick is making sure you mess around in a way that lets you easily hold onto whatever improvements you make. For me that means committing obsessively.

And branches are free.

Re: Who needs Git when you have 1M context windows?

#59

Post by vidarh »

BryantD wrote: post #56
dotancohen wrote: post #4

Don't take this as career advice! This is an amusing anecdote. But the only lesson to be learned is to commit early, commit often.

I think maybe one other lesson, although I certainly agree with yours, and with the other commenters who talk about the unreliability of this particular method? This feels like an argument for using an editor that autosaves history. "Disk is cheap," as they say -- so what if your undo buffer for any given file goes back seven days, or a month? With a good interface to browse through the history? I'm sure there's an e…

My editor syncs the total editing state to disk every few minutes, across all open instances.

I eventually added support for killing buffers, but I rarely do (only if there's stuff I need to purge for e.g. liability reasons). After a few years use, I now have 5726 buffers open (just checked).

I guess I should garbage collect this at some point and/or at least migrate it from the structure that gets loaded on every startup (it's client-server, so this only happens on reboot, pretty much), but my RAM has grown many times faster than my open buffers.

Post reply on HN