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

Show HN: Oak – Git alternative designed for agents

oak.space

Post reply on HN
Print view View original

31–40 of 216 posts

Re: Show HN: Oak – Git alternative designed for agents

#31

Post by z3ugma »

Banditoz wrote: post #13
weinzierl wrote: post #9

"Git is forever" Many things were forever until they suddenly died, but I think this is especially true for git. I'm not saying this as a git hater, quite to the contrary. I think git is great. I also think git is an ill-fit for the majority of modern commercial software projects and there will be a breaking point where companies realize that and move on.

What is git not suited for in modern development? I haven't found any reasons.

Armin and Ben did a nice deepdive on Mercurial vs Git and why hg should have won in a recent episode of their "nerds-chatting" style podcast: https://www.youtube.com/watch?v=JM1sIVIZYRg&t=3813s

Re: Show HN: Oak – Git alternative designed for agents

#33

Post by [deleted] »

gchamonlive wrote: post #27
jayd16 wrote: post #24

Earlier quoted context omitted.

Git is great but if you really haven't found any reasons then you haven't looked at all. From large files to sub modules to hook permissions and file permissions... The list goes on and on about what where git falls short. There's plenty of workarounds too, but that's what they are. Workarounds.

Do you know if Jujutsu addresses these issues?

[deleted]

Re: Show HN: Oak – Git alternative designed for agents

#34

Post by WolfeReader »

Banditoz wrote: post #13
weinzierl wrote: post #9

"Git is forever" Many things were forever until they suddenly died, but I think this is especially true for git. I'm not saying this as a git hater, quite to the contrary. I think git is great. I also think git is an ill-fit for the majority of modern commercial software projects and there will be a breaking point where companies realize that and move on.

What is git not suited for in modern development? I haven't found any reasons.

1. Ease of use. Other VCS have more consistent command line interfaces; Git's interface has to be studied. In practice, people end up using GUIs with missing functionality and then end up searching for help, and a lot of real experts come to rely on powerful wrappers like Magit, LazyGit, or JJ.

(Compare to Mercurial, Fossil or Git; those systems have consistent and usable interfaces. There's much less demand for wrappers or LLM tooling since they're easy to use already.)

2. Preservation of history. Two common commands - git rebate and git push -f - cause commit history to be lost, sometimes permanently. ("Just be careful" and "Just don't use those commands" are useful pieces of advice for an individual, and virtually impossible to enforce over groups.)

3. Conflict resolution. Git forces the user to resolve conflicts ASAP so we often lose information about A. What the conflict exactly was, and B. How the individual resolved it. Most VCS have this issue; JJ allows you to commit the conflict and solve it in a separate commit, which is nice.

Re: Show HN: Oak – Git alternative designed for agents

#35

Post by AdamN »

philipwhiuk wrote: post #20
noelwelsh wrote: post #11

A few comments: * The core idea sounds interesting. Make it the first paragraph, not paragraph seven. * Spend more words describing what makes Oak different. * "I built a version control system in my free-time called Jam". You probably didn't name your free time. "I built a version control system, called Jam, in my free time."

"I built a version control system, in my free-time, called Jam" is fine.

Just "I built a version control system called Jam". The free-time thing is good for a history page but the homepage needs to tell the important part (you've got history and expertise in this subject) and then move onto what the vision is for Oak and what kind of help you need.

Re: Show HN: Oak – Git alternative designed for agents

#36

Post by tlb »

packetlost wrote: post #29
WolfeReader wrote: post #15

Earlier quoted context omitted.

"I wish commits could be folded into larger commits so that you can still capture the individual changes but also not see them by default when looking at the history of a file." Fossil merges do this. More people need to use Fossil; it's got a ton of great ideas. "If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with…

> "If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes." > > Now this is a good idea that I've never seen in a VCS. There's a reason no one has done that, the VCS would have to have a semantic understanding of what it's tracking. I'm sure that's possible, but I think would see extremely limited su…

git actually does this. `git diff --find-copies`

Re: Show HN: Oak – Git alternative designed for agents

#37

Post by Pet_Ant »

packetlost wrote: post #29
WolfeReader wrote: post #15

Earlier quoted context omitted.

"I wish commits could be folded into larger commits so that you can still capture the individual changes but also not see them by default when looking at the history of a file." Fossil merges do this. More people need to use Fossil; it's got a ton of great ideas. "If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with…

> "If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes." > > Now this is a good idea that I've never seen in a VCS. There's a reason no one has done that, the VCS would have to have a semantic understanding of what it's tracking. I'm sure that's possible, but I think would see extremely limited su…

1) An “easy” way to implement this would be to treat the original file as the parent to both files. You can add a new command “split” if needed to mark the new file as a fork of the existing file.

2) language sensitive version control seems like the next thing. We need like an LSP for VCSes.

Re: Show HN: Oak – Git alternative designed for agents

#38

Post by fusslo »

Banditoz wrote: post #13
weinzierl wrote: post #9

"Git is forever" Many things were forever until they suddenly died, but I think this is especially true for git. I'm not saying this as a git hater, quite to the contrary. I think git is great. I also think git is an ill-fit for the majority of modern commercial software projects and there will be a breaking point where companies realize that and move on.

What is git not suited for in modern development? I haven't found any reasons.

1. rewriting history

2. rebase based merge strategies - our team has 50+ devs across three continents merging into monorepo with teams maintaining submodules. By the time your merge request passes CI it has to be rebased. People are literally holding off on reviewing merge requests to make sure their own changes get in first

3. permissions for subdirectories/assets. some necessary code/modules are highly regulated and company secrets. Git cant lock certain directories based on who clones the repo

4. Agentic coding - if you don't commit then your changeset after each request is lost. JJ solves this. You could just say to commit after every request then squash the commits. But, I think this is an ergonomic argument

5. Maybe it's just my experience, but git-lfs is pretty annoying to manage on large teams and changing files to/from lfs. often easier to just delete and clone again

6. git blame on non-meaninful changes. Running a code linter to add/remove whitespace makes git blame return who ran the linter rather than who wrote the code

7. self-reported identity. every time we get new laptops (because they buy the cheapest POS) devs forget what they set for 'username'. so it ends up being 3-4 different identities with the same email

Those are just my complaints lately

Re: Show HN: Oak – Git alternative designed for agents

#40

Post by Pet_Ant »

tlb wrote: post #36
packetlost wrote: post #29

Earlier quoted context omitted.

> "If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes." > > Now this is a good idea that I've never seen in a VCS. There's a reason no one has done that, the VCS would have to have a semantic understanding of what it's tracking. I'm sure that's possible, but I think would see extremely limited su…

git actually does this. `git diff --find-copies`

If I run blame on the new file the will I see the commits made by the original writers? Will it find the same code if it was written independently? It’s not about find copies it about recording changes to a code base as an artifact and not to files. The closest git has is limited rename support.
Post reply on HN