atzanteol

joined 2 years ago
[–] atzanteol@sh.itjust.works 3 points 3 hours ago

It isn't. This community is basically "news" at this point.

[–] atzanteol@sh.itjust.works -1 points 4 hours ago (2 children)
[–] atzanteol@sh.itjust.works 3 points 4 hours ago (4 children)

Looking at the table above AI gpus are a pure scam

How much more power are your gaming GPUs going to use? How much more space will they use? How much more heat will you need to dissipate?

[–] atzanteol@sh.itjust.works 5 points 4 hours ago (1 children)

I meant the "waiting too late to start evacuating children" being the wrong call.

[–] atzanteol@sh.itjust.works 1 points 4 hours ago

One takes them from the last commit log and uses the first few letters

So - it's not the length of the random garbage that is the issue it's the fact that it's random garbage that I have no chance of remembering after 5 seconds and switching between branches. All my branches are instead random hashes that I'll need to lookup or remember.

I've read through the blog. It sounds like they've taken the minor inconvenience of doing a git merge --squash and distributed that pain across every-single-commit you're ever going to make instead. All to get "tidy commits" which were possible before anyway.

I was actually rather interested in the idea of jj being something that made history-rewriting easier (e.g. for removing bad commits with passwords and the like). But the fact that it almost completely throws out the entire concept of working on named branches (yes you can have them - but "One interesting thing about branches in jj that's different than branches in git is that branches do not automatically move." - genius) is just ridiculous. And to claim that it's now simpler just seems like gaslighting.

[–] atzanteol@sh.itjust.works 1 points 4 hours ago

Don't be stupid.

[–] atzanteol@sh.itjust.works 1 points 5 hours ago (4 children)

If the readability of the commit history really does not matter to you - for exsmple, nobody needs to read this code again - it’s possible that jj does not give you enough advantage. Everyone works different.

I mean... It does and I will use git to manage commit histories as necessary. I don't see jj as solving that problem or even making it easier. Doing a single squash-commit or a rebase -i when I merge a branch is relatively trivial.

And from what I can tell it's much easier to do a git pull upstream master than to do jj new skdfsld dskfjas since you'll likely have to lookup those hashes? I mean I wouldn't remember them.

[–] atzanteol@sh.itjust.works 0 points 6 hours ago

Did op know one of their options was to not post a stupid question?

[–] atzanteol@sh.itjust.works 8 points 9 hours ago* (last edited 9 hours ago) (3 children)

People are heuristic - we predict the future from our past experiences. They have been on the river for 40 years and had a lot of experience telling them that "this will be like other times."

Maybe there was even a time where it was far less than what NOAA predicted.

This is why scientific literacy and critical thinking skills are important. One of the deadliest phrases is "in my experience".

Dick Eastland died trying to rescue some of the youngest girls.

Imagine realizing you made the wrong call by hearing the screams of children.

[–] atzanteol@sh.itjust.works -1 points 10 hours ago

Hey - I would like to get into your hobby and have done literally no research about it - which is the best to get to start with?

[–] atzanteol@sh.itjust.works 3 points 10 hours ago (1 children)

Technically true - but it looks like jj does a lot of history re-writing which would require a lot of care to be taken when working on a shared codebase.

The page on remotes has some cautions in it.

We need the --allow-backwards flag to set the trunk branch to the previous commit because it is a dangerous operation: if we had pushed trunk, things would get weird when we try and push now. We've kept it all local, so there's no issues with doing this.

[–] atzanteol@sh.itjust.works 3 points 10 hours ago* (last edited 10 hours ago) (7 children)

Hrm... It looks interesting but it seems too dedicated to crafting "the perfect commit".

Changing our description changed the commit ID! This is why we have both IDs: the change ID has not changed, but the commit ID has. This allows us to evolve our commit over time, but still have a stable way to refer to all versions of it.

I don't want to "evolve a commit" - I want to capture my changes over time. If I decide later that I want to prepare the commit for merging I will.

I hate it because it's different - but even trying to give it a "benefit of the doubt" I really can't see this as better. It's not like it's difficult to create a "tidy" commit with git as is.

And as far as "easier to use goes"... well... Here's how you get a list of anonymous branches

jj log -r 'heads(all())'

And since they eschew branches with names you get to memorize hash strings instead of branch names that describe the thing you were doing?

jj new pzoqtwuv yykpmnuq -m "merge better documentation"
# vs. 
git merge my_branch_Name

I'm unconvinced. Though jj undo looks neat (and also crazy dangerous unless you can undo an undo?).

 

Two days after catastrophic floods roared through Central Texas, the Federal Emergency Management Agency did not answer nearly two-thirds of calls to its disaster assistance line, according to documents reviewed by The New York Times.

The lack of responsiveness happened because the agency had fired hundreds of contractors at call centers, according to a person briefed on the matter who spoke on the condition of anonymity in order to discuss internal matters.

 

Health secretary Robert F. Kennedy Jr.’s advisers ordered the release of a dataset that includes the private health information of people living in California, Illinois, Washington state, and Washington, D.C., to the Department of Homeland Security

 

Our longstanding offering won’t fundamentally change next year, but we are going to introduce a new offering that’s a big shift from anything we’ve done before - short-lived certificates. Specifically, certificates with a lifetime of six days. This is a big upgrade for the security of the TLS ecosystem because it minimizes exposure time during a key compromise event.

 

If you're self hosting roundcube be sure to update.

view more: next ›