Hacker News new | ask | show | jobs
by mjr00 91 days ago
There's nothing clean about the history. You think commits like [0], with the commit message "improve", count as "clean"? What do you think the motivation for the author would be to modify git history to make it appear that this was written over a weekend, including separating each feature/commit by a few hours, which corresponds to a reasonable amount of time that it may have taken to write that feature? Including a break on Mar 15 at 1:18 AM PDT before continuing to commit at Mar 15 at 12:43 PM PDT. Hey, isn't there a normal human behaviour that occurs around this time every day which takes 6-10 hours?

I'm fully aware you can rewrite git history to whatever you want, but this is an occam's razor situation here. You'd only think this wasn't a weekend project if you desperately wanted to believe that this was some major initiative for some reason.

[0] https://github.com/NVIDIA/NemoClaw/commit/b9382d27d13b160dcf...

1 comments

Just let go of the notion that a 4 day github history necessarily means the project is only 4 days old. It's a ridiculous assumption to base an argument off of. It's extremely normal to have work in one, perhaps internal, repo which you then blast over to a public repo in one (or a few) big commits. There is zero reason for them to let you see their internal progress.
> It's extremely normal to have work in one, perhaps internal, repo which you then blast over to a public repo in one (or a few) big commits.

Did you even read the commit history? That is not what is happening here.

This is turning into a "don't believe your lying eyes" situation. Why are you people so desperate to pretend this wasn't written in a weekend?

> There is zero reason for them to let you see their internal progress.

Again, I ask you -- what is the reason for them to edit commit history to show incremental progress as if it were written in a weekend, when it actually was not?

I don't have to know their reasoning in order to know public github history is not necessarily an accurate record of all changes.
Okay, so there's overwhelming evidence that their public github history is accurate and Nemoclaw was written in a weekend, and the only reason to think it's not accurate is that... it's technically possible to edit git history, and also there's no reasonable explanation for why they would have edited git history they way they did.

So... yeah, draw your own conclusion I guess, whatever.

> there's overwhelming evidence that their public github history is accurate and Nemoclaw was written in a weekend

Aside from commits on github, which we've already established mean absolutely nothing, what is the overwhelming evidence?

Lmfao. This is how I know you have never worked at a big company before. I promise you every big company has processes around open sourcing things. It's not something that just whip up and release over a weekend. Just the legal approval would have taken months

I have buddies at Nvidia. Their primary platform is not GitHub. Sorry you're so naive. Almost certainly this was built in house for at least a month or two prior. Then private repo. Approvals. Then public

Not to mention the fact that Jensen literally announced it in their biggest yearly launch conference. No you're totally right. He mandated someone build it over the weekend while drafting up a full presentation and launch announcement about it

That's more plausible than the very normal practice of developing internally, scrubbing commits of any accidental whoopsies, vetting it and then putting it out publicly

"Overwhelming evidence" = git history that is completely fungible. Once you're done here I have a lobster claw to sell you

> Again, I ask you -- what is the reason for them to edit commit history to show incremental progress as if it were written in a weekend, when it actually was not?

Answer this question or we're done here, thanks.

> Almost certainly this was built in house for at least a month or two prior. Then private repo. Approvals. Then public.

Source, other than you making it up?

> That's more plausible than the very normal practice of developing internally, scrubbing commits of any accidental whoopsies, vetting it and then putting it out publicly

Could you point to a specific commit you believe is a representation of an internal data transfer from a separate source control system which is not representative of work achievable within the time period represented by the differential between the commit time and the time of the prior commit?