Live data from Hacker News

I found a useful Git one liner buried in leaked CIA developer docs

spencer.wtf

61–70 of 273 posts

Re: I found a useful Git one liner buried in leaked CIA developer docs

#61

Earlier quoted context omitted.

how do you trust the code claude wrote? don't you get anxiety "what if there's an error in tui code and it would mess up my git repo"?

Isn't it this case no matter who wrote the code? How do you ever run anything if you're worried about bugs?

When I write the code myself, I'm not worried that I snuck a `git reset --hard` somewhere.

Re: I found a useful Git one liner buried in leaked CIA developer docs

#65
post #40
post #24

Speaking of user friendliness of git UI. I am working on a revision control system that (ideally) should be as user friendly as Ctrl+S Ctrl+Z in most common cases. Spent almost a week on design docs, looking for feedback (so far it was very valuable, btw) https://replicated.wiki/blog/partII.html#navigating-the-hist...

Have you tried Jujutsu? If you want to make a better VCS, your baseline should be that, in my opinion, because it already deals with a lot of the Git pain points whilst be able to read and publish to Git repositories.

The idea of using git as a blob storage and building entire new machinery on top is definitely a worthy one. At this point though, the de-facto baseline is no doubt git. If git as a store withstands the abuse of jj and jj becomes the industry standard, then I would agree with you. Also, at that point they may drop git backend entirely just because of price/performance discrepancy. git is overweight for what it does, if they make it do only the bottom 20%, then things will get funny.

Still, many oddities of git are inevitable due to its underlying storage model, so it makes sense to explore other models too.

Re: I found a useful Git one liner buried in leaked CIA developer docs

#66

Wait, why would the update for the silly master->main change be swapping the excluded regex instead of just excluding both?

coz OP has agenda and

> Since most projects now use main instead of master

some delusions to boot

Re: I found a useful Git one liner buried in leaked CIA developer docs

#67
post #37

Earlier quoted context omitted.

Can you explain TUI? I have never heard this before

[flagged]

I don't know when the term became widespread for gui-style terminal programs, but the wikipedia entry has existed for more than 20 years so I think it is an older term than you imply.

https://en.wikipedia.org/w/index.php?title=Text-based_user_i...

Re: I found a useful Git one liner buried in leaked CIA developer docs

#69
post #64

Dont most git instances, like github, delete branch after a PR was merged, by default? I am not sure under what usecases, you will end up with a lot of stale branches. And git fetch -pa should fix it locally

In Github it needs to be explicitly configured (Settings > General > Delete head branches after merging), Gitlab is the same.

A lot of my developer colleagues don't know how git works, so they have no idea that "I merged the PR" != "I deleted the feature branch". I once had to cleanup a couple repositories that had hundreds of branches spanning back 5+ years.

Nowadays I enforce it as the default project setting.

Re: I found a useful Git one liner buried in leaked CIA developer docs

#70
post #64

Dont most git instances, like github, delete branch after a PR was merged, by default? I am not sure under what usecases, you will end up with a lot of stale branches. And git fetch -pa should fix it locally

`--prune` will delete your local copies of the origin's branches (e.g. `origin/whatever`). But it won't delete your local branches (e.g. `whatever` itself). So PRs that you've worked on or checked out locally will never get deleted.
Post reply on HN