[flagged]
Show HN: Oak – Git alternative designed for agents
191–200 of 216 posts
Re: Show HN: Oak – Git alternative designed for agents
#192Re: Show HN: Oak – Git alternative designed for agents
#193Anything "for agents" needs to provide some kind of evidence it's better than what the agents already have baked into the model training data. It can't just be "easier" on some dimension, because the model has already learned the hard parts of the old thing and models can't make new memories to learn new things, so there is always a context cost for the new thing. Models know git because there's a monstrous amount of…
I'm not sure I understand this argument. I create new tools all the time as part of my development work, and I have skills stored that tell agents how to use them. They use them flawlessly. When I say "benchmark the query engine using the foobar dataset and compare it to run 431", the agents go and run my special benchmark tool and use the different subcommands to compare results and so on. I'm sure a new VCS would b…
> I'm not sure I understand this argument. I create new tools all the time as part of my development work, and I have skills stored that tell agents how to use them. They use them flawlessly.
I highly doubt that your tool is like this:
> git branch -vv | grep ': gone]'| grep -v "*" | awk '{ print $1; }' | xargs -r git branch -d
Or:
> ffmpeg -i main_course.mp4 -i reaction_cam.mov \ -filter_complex \ "[1:v]scale=480:270[pip_scaled]; \ [0:v][pip_scaled]overlay=W-w-20:20[pip_video]; \ [pip_video]drawtext=text='LIVE RECORDING':fontcolor=white:fontsize=24:box=1:boxcolor=black@0.6:x=30:y=30[final_video]; \ [0:a][1:a]amix=inputs=2:duration=first:dropout_transition=2[final_audio]" \ -map "[final_video]" -map "[final_audio]" \ -c:v libx264 -crf 21 -preset fast \ -c:a aac -b:a 192k \ output_production.mp4
LLMs generate these for breakfast.
Re: Show HN: Oak – Git alternative designed for agents
#194[flagged]
Re: Show HN: Oak – Git alternative designed for agents
#195Earlier quoted context omitted.
I'm not sure I understand this argument. I create new tools all the time as part of my development work, and I have skills stored that tell agents how to use them. They use them flawlessly. When I say "benchmark the query engine using the foobar dataset and compare it to run 431", the agents go and run my special benchmark tool and use the different subcommands to compare results and so on. I'm sure a new VCS would b…
> I'm not sure I understand this argument. I create new tools all the time as part of my development work, and I have skills stored that tell agents how to use them. They use them flawlessly. I highly doubt that your tool is like this: > git branch -vv | grep ': gone]'| grep -v "*" | awk '{ print $1; }' | xargs -r git branch -d Or: > ffmpeg -i main_course.mp4 -i reaction_cam.mov \ -filter_complex \ "[1:v]scale=480:27…
It’s really wild watching LLMs construct those calls. They batch so many different checks and stuff into a single tool call, delimit them with markers, etc.
The crazy thing to me is that this kind of “composition of small tools to create something bigger” is the biggest vindication of the Unix philosophy I can think of.
I have to wonder how much of that behavior was trained into the model and how much it is the secret herbs and spices they toss into the harnesses own system prompts.
Re: Show HN: Oak – Git alternative designed for agents
#196Anything "for agents" needs to provide some kind of evidence it's better than what the agents already have baked into the model training data. It can't just be "easier" on some dimension, because the model has already learned the hard parts of the old thing and models can't make new memories to learn new things, so there is always a context cost for the new thing. Models know git because there's a monstrous amount of…
Totally agree. I used to work with a team that built a project for creating ontologies of Git repositories. The goal was to help LLMs onboard faster and navigate the repo better.
In the end, it became heavy overengineering: people no longer understood not only the repo itself, but also the extra layer describing it. Meanwhile, coding assistants are already quite good at reading codebases directly.
Re: Show HN: Oak – Git alternative designed for agents
#197Earlier quoted context omitted.
He earned a PhD…
Still not a doctor, as he himself confirmed.
A PhD is a Doctor of Philosophy, so unless that PhD has been invalidated he is in fact a doctor. I don't know his personal preferences so perhaps he doesn't like to be referred to as a doctor (based solely on what you're saying). But there was nothing factually incorrect about the poster saying "Dr. Hipp."
Re: Show HN: Oak – Git alternative designed for agents
#198Earlier quoted context omitted.
Mostly true, but the weird edge case I run into is workspaces. Since they seem to be independent of and not backward compatible with git worktrees, there is no fall back to git for submodules within a workspace. We still use submodules in a number of places at work so it’s a bit of friction for me. Other than that, I’m rapidly becoming a jj convert.
Ahh, so workspaces don't currently support colocation, aka "put a .git directory in there". So that's what's up there. Interesting corner case! I know upstream is working on it.
The repos i work in are hard-coupled to being in a git repo. So in order to make jj workspaces work for me, I've had to do the very hacky thing of literally copying the .git directory into the other workspaces.
It actually works quite well and has never caused me any issues. I tried symlinking but that does not work, git doesn't like the .git being a symlink.
Re: Show HN: Oak – Git alternative designed for agents
#199Earlier quoted context omitted.
Submodules are already that way as well.
Mostly true, but the weird edge case I run into is workspaces. Since they seem to be independent of and not backward compatible with git worktrees, there is no fall back to git for submodules within a workspace. We still use submodules in a number of places at work so it’s a bit of friction for me. Other than that, I’m rapidly becoming a jj convert.
Try just copying the .git directory into the other workspaces. It's worked great for me when working in repos that have tooling that is coupled to git.
Re: Show HN: Oak – Git alternative designed for agents
#200Earlier quoted context omitted.
> I'm not sure I understand this argument. I create new tools all the time as part of my development work, and I have skills stored that tell agents how to use them. They use them flawlessly. I highly doubt that your tool is like this: > git branch -vv | grep ': gone]'| grep -v "*" | awk '{ print $1; }' | xargs -r git branch -d Or: > ffmpeg -i main_course.mp4 -i reaction_cam.mov \ -filter_complex \ "[1:v]scale=480:27…
It’s really wild watching LLMs construct those calls. They batch so many different checks and stuff into a single tool call, delimit them with markers, etc. The crazy thing to me is that this kind of “composition of small tools to create something bigger” is the biggest vindication of the Unix philosophy I can think of. I have to wonder how much of that behavior was trained into the model and how much it is the secre…
Personally I really dislike when the agents generate super long composed shell commands because they are really hard to audit. ffmpeg I'd whitelist, but if it makes a mistake in some super long chained git command it can have pretty scary consequences.